Finding the DateTime field that is not initialized - entity-framework

We are saving more than one entity type in one unit of work. There are many DateTime fields in each entity-type. Sometimes, an SqlDateTime overflow exception occurs because a DateTime field is not initialized.
To find the field/property that causes the problem is an annoying task. Does anybody know a debugging technique to find out which field is causing the problem? To check every field is cumbersome.
Thanks a lot for hints.

If you're using the DateTime? nullable type then you can use the property hasValue to check if it is null. If you're using DateTime then I believe it defaults to the min value which is DateTime.MinValue and can be easily checked. The MinValue is something insane like the year Jan 1st 0001, so it makes sense that SQL wouldn't like that
If you're taking something out of the db, then a standard null check works fine.

Related

grails 3.3.x java.sql.Date property is type-mismatched

In my domain class, I have something like this:
class User {
String name
java.sql.Date birthDate
}
I am getting the app working with scaffolding, and the scaffolded creation pages correctly show the d/m/y drop down date picker to specify the date, which is very good.
But when I hit the "Create" button, it gives:
Property birthDate is type-mismatched"
I am using the built in H2 DB currently, but will switch to MySQL later.
Any suggestions? I don't want to use the normal date/time as I only need the date, and it must not be affected by time zones. Obviously I could manually store the day, month and year fields separately, but this makes it harder to use later (e.g. for comparison).
We had a trick to get this working with Grails 2.x, but I don't have a copy of this old code.
Does anyone have a workaround for getting this working with the fields plugins?
In my update controller method, even if I manually set user.birthDate to a correct java.sql.Date instance, calling user.save() still fails with the type-missmatch error. It seems to be something in the save() method, which is presumably GORM code.

Choosing between text, string, date, date/time (MDriven)

Which one of the following is preferably used when creating an attribute containing data on when something was established:
"String"
"Text"
"Date"
"Date/Time"
?
Researching, I found that both "String" and "Date" should be able to create "(YYYY-MM-DD)" equally well.
I also found earlier posts here on SO with titles like this one: How to convert date(string type) into date(date time ) in oracle
Obviously there's a point I've missed here. Surely there's a benefit for using one over the other.
(I'm working in MDriven)
Many thanks.
DateTime should be correct. You may also achieve this in MDriven by using a superclass that by inheritance gives all your objects a set of attributes for creation and change. This will give you "automatic" support, if you want the user to enter, then use an attribute with type "DateTime"

MongoDB Datetimefield Null Error

I am trying to save a null value in a dateTimeField object in MongoDB. I have a date I only want set after a certain condition has been fulfilled, but my site has the ability to save an object multiple time to the database before this variable will be set to anything other than a null or empty string value. I tried using db.dateTimeField(null=True) in my model file per Mongo's documentation to save a null value, but I still get an error when trying to save to the database.
According to this issue on Github, there is some inconsistent behavior with setting null values to dateTimeFields. Does anyone know if this has been fixed? I have a work around (adding my attribute to my object, then assigning it a value right before saving, therefore bypassing the need to save a null value, but it is a bit hacky, and I would like to use MongoDB's built in functionality if possible).
Thanks in advance!

What is a good name for a Date field

Which of these do you think are the best names for date fields?
createdOn/updatedOn
createdDate/updatedDate
creationDate/updatationDate
Other options? Thank you!
I realized some go better with "_On", like "createdOn" and "updatedOn", while others go better with "_Date", like "startDate", "endDate", "dueDate", etc.
That depends on the sort of date field, where you use the field for. I usually use creationDate or createdOn.
It really depends on the platform, language, environment, etc.
You might just use Created or Updated. After all, you probably wouldn't qualify other field names like NameString or LengthInteger.
One convention I do use sometimes is to qualify date fields for what their values represent. For example, some database types like datetime in MS SQL Server don't track what type of date you are working with. Since many people store UTC values in these fields, you might call the field CreatedUTC to give the developer some clue about what type of value is in there.

Diffrence between "Created On" and "Record Created On"

In CRM, when I'm, trying to set up a work flow, I get to choose the timeout to be related to a certain entity's creation time. There are three fields to relate to.
Record Created On
Created On
Modified On
While the last one is very obvious, I can't see any logical difference between the two others.
The difference is that Created On (createdon) is filled out automatcally by the server when you actually create the record, while Record Created On (overriddencreatedon) will usually be null (unless the record was imported into CRM and you chose to explicitly override the record creation date to match when it was created in another system).
You should use the first and skip the latter, as it's not supported (as far I've got it right when I talked to a MVP about it). Why it show, she had no idea and neither do I. Maybe #JamesWood has a shot. He usually does. (sucking-up in progress)
I've never used the latter and I believe you'll keep your hair off-grey and on-head if you stick to the same approach.
From the SDK:
The createdon attribute specifies the date and time that the record was created. To import data in the createdon attribute, map the source column that contains this data to the overriddencreatedon attribute.
During import, the record’s createdon attribute is updated with the value that was mapped to the overriddencreatedon attribute and the overriddencreatedon attribute is set to the date and time that the data was imported.
If no source value is mapped to the overriddencreatedon attribute, the createdon attribute is set to the date and time that the data was imported and the overriddencreatedon attribute is not set to any value.
Link to BlogSpot
Link to Social MSDN