I understand this behavior now, but my expectation when I first started using transfer (way back when) was that a nullable column would default to null.
I long ago got over this and do exactly what you intended and that is to use configure to set default values. I think the real confusion arises because the default values for string and numeric correspond to the default null values, so it appears as if that they default to null, but date defaults to the default value which does not correspond to null. It's just not intuitive to most people I think. On Sun, Jan 11, 2009 at 1:11 PM, Mark Mandel <mark.man...@gmail.com> 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 <sylvan.mes...@gmail.com>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 >> <quackfu...@gmail.com>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: mark.man...@gmail.com > 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 transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
