Jon, thanks for the info. I've not previously noticed that, and I'm not
really sure why I have not noticed it, seeing as that behavior has obviously
been around for a really long time now. (I looked back at a couple of my
old decorators and they're using configure() to default the dates, so maybe
I just don't remember noticing it before?) Now that it has been pointed out
though, I must admit, I'm with you and Dan on this one. If a string
defaults to its "null" of an empty string, and a numeric value defaults to
its "null" of 0, then yeah, a date should default to its "null" value.
On Sun, Jan 11, 2009 at 2:23 PM, Jon Messer 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()...
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
