I have an enhancement around in the issue tracker, such that you can
configure whatever default values you want in the transfer.xml... that would
make everyone happy :D

Mark

On Mon, Jan 12, 2009 at 8:21 AM, Dan Wilson <[email protected]> wrote:

> 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
>
> >
>


-- 
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to