You know, I read those pages before I sent my email this morning and I'll agree It makes sense if I read each page in isolation and not in the context of an application nor in the context of the XML descriptors in the Transfer.xml
However, semantically, I'd expect the following XML to default a property to the null value: <property name="EndDate" type="date" nullable="true" /> Not to now(). I'm actually not sure why anyone would specify any datefield as nullable but want a default of now(). This doesn't seem to fit any use case that comes to mind, though I might be narrowly focused on the application at hand. What I would like to see is any nullable property will be null for any newly created object. DW On Sun, Jan 11, 2009 at 4:11 PM, Mark Mandel <[email protected]> wrote: > 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 > > > > -- "Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew." Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
