I think I see where the confusion lies. Th default VALUE for any given property is listed here: http://docs.transfer-orm.com/wiki/Default_Property_Values.cfm
No matter if the property is nullable or not, this is the default value it will be set to. When discussing 'default null values', i.e. http://docs.transfer-orm.com/wiki/Handling_Null_Values.cfm This is the default value that the property will be set to, IF it is set to being NULL. Does that make more sense? Mark On Mon, Jan 12, 2009 at 7:23 AM, Jon Messer <[email protected]> wrote: > Matt it's pretty easy to reproduce, just create a nullable date property on > any object, then dump the memento of a new instance of that object. The date > will be now() not "null" (01/01/100). > > Whether or not one should have nullable attributes is another topic, but > the reality is there are a lot of data schemas out there that do, and to > assume the default behavior to be now() instead of null seems odd to me. > > So I too was annoyed by this when I first noticed it, now I just write a > config method for every object that has a nullable date. But doing this > seems like an unnecessary work around to inconsistant behavior on the part > of transfer. > > I think date should behave like the other data types with respect to null > and defaults. If I have a nullable string property it defaults to null (''), > a nullable number defaults to null (0), a nullable date defaults to now() > instead of the configured null value for a date... > > Just my opinion though, and I'm sure there are people that would naturally > expect a date property to default to now()... > > > > > > On Sun, Jan 11, 2009 at 11:42 AM, Matt Quackenbush > <[email protected]>wrote: > >> I must admit that I am a bit confused. According to the config file docs >> (http://docs.transfer-orm.com/wiki/Transfer_Configuration_File.cfm), the >> default value for a null date is 1/1/100, the oldest date that CF will >> recognize as a date. This has been the behavior that I have personally >> experienced. >> >> I've never noticed a default of now(). Perhaps there is a specific set of >> circumstances under which this now() thing takes place and I've just never >> "found" these circumstances? I am quite curious and confused. >> >> >> On Sun, Jan 11, 2009 at 11:59 AM, Dan Wilson wrote: >> >>> I found this thread after dealing with the default now() for dates as >>> well. I do not like how this works at all and this does not represent the >>> behaviour I would expect. >>> I would expect a date field, when configured with a nullable property, to >>> default to the appropriate value for a nullable property. Why on Earth a >>> null date defaults to now() is beyond my comprehension and frankly is >>> annoying. This seems a lot like a bug, not a feature. >>> >>> Perhaps I misunderstand? >>> >>> DW >>> >> >> >> >> > > > > -- E: [email protected] W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
