Nullable Values - still don't get it
3 views
Skip to first unread message
Jared
Nov 28, 2008, 4:28:51 PM11/28/08
to transfer-dev
I read through this thread, but I still don't understand how to handle
the problem where date properties of a transfer object default to Now
(). I find that weird. Why don't they default to the null value for
dates? Setting them to Now() is a bit like defaulting string values
to "hello there" or defaulting numeric values to 17. I can't write a
configure method to handle this, since I don't want to always set the
date values to null (or whatever stands in for null, since CF doesn't
have null (which is annoying)). I only want to do so in response to
Transfer.new(). The only thing I can think of is to write a method in
my decorator called nullifyDates() that goes through each date and
does a setMyDatePropertyNull(). Then, whenever I do a new() for this
type of object I would, on the next line, do a myObj.nullifyDates() to
fix the weirdness of dates defaulting to Now(). Seems like a bit of a
hack. Is that the only way?
That said, transfer is great! Long live transfer. Send Mark money.
the problem where date properties of a transfer object default to Now
(). I find that weird. Why don't they default to the null value for
dates? Setting them to Now() is a bit like defaulting string values
to "hello there" or defaulting numeric values to 17. I can't write a
configure method to handle this, since I don't want to always set the
date values to null (or whatever stands in for null, since CF doesn't
have null (which is annoying)). I only want to do so in response to
Transfer.new(). The only thing I can think of is to write a method in
my decorator called nullifyDates() that goes through each date and
does a setMyDatePropertyNull(). Then, whenever I do a new() for this
type of object I would, on the next line, do a myObj.nullifyDates() to
fix the weirdness of dates defaulting to Now(). Seems like a bit of a
hack. Is that the only way?
That said, transfer is great! Long live transfer. Send Mark money.
Paul Marcotte
Nov 28, 2008, 4:59:29 PM11/28/08
to transf...@googlegroups.com
Hi Jared,
You can call nullifyDates() in the configure method of your decorator. Transfer will fire the configure method before returning the new object.
Paul--
Paul Marcotte
Fancy Bread - in the heart or in the head?
http://www.fancybread.com
You can call nullifyDates() in the configure method of your decorator. Transfer will fire the configure method before returning the new object.
Paul
Paul Marcotte
Fancy Bread - in the heart or in the head?
http://www.fancybread.com
Paul Marcotte
Nov 28, 2008, 5:03:39 PM11/28/08
to transf...@googlegroups.com
Ooops, I misread your post. You could use an afterNew Observer instead. But I'm wondering if configure is fired even on get()?
***heads to docs...
Paul
***heads to docs...
Paul
Mark Mandel
Nov 28, 2008, 5:31:28 PM11/28/08
to transf...@googlegroups.com
On a get the following happens:
- creates new object
- configure() gets called
- object gets populated
- object is returned.
So anything inside configure() is overwritten by populated data.
Mark
--
E: mark....@gmail.com
W: www.compoundtheory.com
- creates new object
- configure() gets called
- object gets populated
- object is returned.
So anything inside configure() is overwritten by populated data.
Mark
E: mark....@gmail.com
W: www.compoundtheory.com
CKCarter
Dec 9, 2008, 4:37:45 PM12/9/08
to transfer-dev
We've been dealing with this same issue, and not to nitpick but I note
that his question about the "why" was ignored but work-around
solutions offered instead. Especially since every other value type
defaults to the default null value of its type, only date fields have
a non-null-like value as their default on creation.
Would a patch that adds the necessary code and a configuration file
option to have dates default to their null values be considered? From
what a 10-minute eval reveals it seems that it should not take more
than a few lines of code to add the alternative behavior and
configuration file support.
Thankfully Paul points out a one time solution use Observers, which is
likely the direction we will go in the short term.
And Ditto with Jared, Transfer rocks very hard. Somebody tell Adobe to
get Mark a "valuable-contributor" dividend going so he can write more
neat stuff.
-- Kevin Carter
On Nov 28, 5:31 pm, "Mark Mandel" <mark.man...@gmail.com> wrote:
> On a get the following happens:
>
> - creates new object
> - configure() gets called
> - object gets populated
> - object is returned.
>
> So anything inside configure() is overwritten by populated data.
>
> Mark
>
>
>
> On Sat, Nov 29, 2008 at 9:03 AM, Paul Marcotte <pmarco...@gmail.com> wrote:
> > Ooops, I misread your post. You could use an afterNew Observer instead.
> > But I'm wondering if configure is fired even on get()?
>
> > ***heads to docs...
>
> > Paul
>
> E: mark.man...@gmail.com
> W:www.compoundtheory.com
that his question about the "why" was ignored but work-around
solutions offered instead. Especially since every other value type
defaults to the default null value of its type, only date fields have
a non-null-like value as their default on creation.
Would a patch that adds the necessary code and a configuration file
option to have dates default to their null values be considered? From
what a 10-minute eval reveals it seems that it should not take more
than a few lines of code to add the alternative behavior and
configuration file support.
Thankfully Paul points out a one time solution use Observers, which is
likely the direction we will go in the short term.
And Ditto with Jared, Transfer rocks very hard. Somebody tell Adobe to
get Mark a "valuable-contributor" dividend going so he can write more
neat stuff.
-- Kevin Carter
On Nov 28, 5:31 pm, "Mark Mandel" <mark.man...@gmail.com> wrote:
> On a get the following happens:
>
> - creates new object
> - configure() gets called
> - object gets populated
> - object is returned.
>
> So anything inside configure() is overwritten by populated data.
>
> Mark
>
>
>
> On Sat, Nov 29, 2008 at 9:03 AM, Paul Marcotte <pmarco...@gmail.com> wrote:
> > Ooops, I misread your post. You could use an afterNew Observer instead.
> > But I'm wondering if configure is fired even on get()?
>
> > ***heads to docs...
>
> > Paul
>
> W:www.compoundtheory.com
Mark Mandel
Dec 9, 2008, 4:41:44 PM12/9/08
to transf...@googlegroups.com
On Wed, Dec 10, 2008 at 8:37 AM, CKCarter <ckec...@gmail.com> wrote:
>
> Would a patch that adds the necessary code and a configuration file
> option to have dates default to their null values be considered? From
> what a 10-minute eval reveals it seems that it should not take more
> than a few lines of code to add the alternative behavior and
> configuration file support.
>
> Would a patch that adds the necessary code and a configuration file
> option to have dates default to their null values be considered? From
> what a 10-minute eval reveals it seems that it should not take more
> than a few lines of code to add the alternative behavior and
> configuration file support.
This is why configure() exists... because not all default values are
equal for all people.
Some people may like Now(), some people will want the null value.
I had an enhancement ticket lying around, so you could configure
default values globally across Transfer via the transfer.xml, but not
sure where I put it.
Mark
Dan Wilson
Jan 11, 2009, 12:59:03 PM1/11/09
to transf...@googlegroups.com
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.
DW
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
--
"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
"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
Matt Quackenbush
Jan 11, 2009, 2:42:52 PM1/11/09
to transf...@googlegroups.com
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.
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.
Jon Messer
Jan 11, 2009, 3:23:48 PM1/11/09
to transf...@googlegroups.com
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()...
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()...
Mark Mandel
Jan 11, 2009, 4:11:34 PM1/11/09
to transf...@googlegroups.com
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
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
Dan Wilson
Jan 11, 2009, 4:21:08 PM1/11/09
to transf...@googlegroups.com
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
Jon Messer
Jan 11, 2009, 4:22:36 PM1/11/09
to transf...@googlegroups.com
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.
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.
Mark Mandel
Jan 11, 2009, 4:43:11 PM1/11/09
to transf...@googlegroups.com
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
Mark
Matt Quackenbush
Jan 11, 2009, 8:05:02 PM1/11/09
to transf...@googlegroups.com
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.
Kevin Roche
Jan 12, 2009, 7:05:02 AM1/12/09
to transf...@googlegroups.com
il.com> <bafef870901111223t52d...@mail.gmail.com> <d01ae6560901111705o31c...@mail.gmail.com>
In-Reply-To: <d01ae6560901111705o31c...@mail.gmail.com>
Subject: RE: [transfer-dev] Re: Nullable Values - still don't get it
Date: Mon, 12 Jan 2009 12:04:07 -0000
Message-ID: <0d0001c974ad$df49cdd0$9ddd6970$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0D01_01C974AD.DF49CDD0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acl0UMUdNBRAUY6YSkaKCqA+/XYNUwAXABSw
Content-Language: en-gb
This is a multipart message in MIME format.
------=_NextPart_000_0D01_01C974AD.DF49CDD0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
I noticed this too a while ago. I thought it was me doing something wrong
and set the value myself.
Kevin Roche
------=_NextPart_000_0D01_01C974AD.DF49CDD0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I noticed this too a while ago. I thought it was me doing =
something
wrong and set the value myself.<o:p></o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Kevin Roche<o:p></o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>
<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> transf...@googlegroups.com
[mailto:transf...@googlegroups.com] <b>On Behalf Of </b>Matt =
Quackenbush<br>
<b>Sent:</b> 12 January 2009 01:05<br>
<b>To:</b> transf...@googlegroups.com<br>
<b>Subject:</b> [transfer-dev] Re: Nullable Values - still don't get =
it<o:p></o:p></span></p>
</div>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Jon, thanks for the =
info.
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.<br>
<br>
<o:p></o:p></p>
<div>
<p class=3DMsoNormal>On Sun, Jan 11, 2009 at 2:23 PM, Jon Messer =
wrote:<o:p></o:p></p>
<p class=3DMsoNormal>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). <br>
<br>
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.<br>
<br>
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.<br>
<br>
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... <br>
<br>
Just my opinion though, and I'm sure there are people that would =
naturally
expect a date property to default to now()...<o:p></o:p></p>
</div>
<p class=3DMsoNormal><br>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
Before posting questions to the group please read: <br>
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-qu... =
<o:p></o:p></p>
<p style=3D'margin-bottom:12.0pt'>You received this message because you =
are
subscribed to the Google Groups "transfer-dev" group. <br>
To post to this group, send email to transf...@googlegroups.com <br>
To unsubscribe from this group, send email to
transfer-dev...@googlegroups.com <br>
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=3Den<br>
-~----------~----~----~----~------~----~------~--~---<o:p></o:p></p>
</div>
</body>
</html>
------=_NextPart_000_0D01_01C974AD.DF49CDD0--
In-Reply-To: <d01ae6560901111705o31c...@mail.gmail.com>
Subject: RE: [transfer-dev] Re: Nullable Values - still don't get it
Date: Mon, 12 Jan 2009 12:04:07 -0000
Message-ID: <0d0001c974ad$df49cdd0$9ddd6970$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0D01_01C974AD.DF49CDD0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acl0UMUdNBRAUY6YSkaKCqA+/XYNUwAXABSw
Content-Language: en-gb
This is a multipart message in MIME format.
------=_NextPart_000_0D01_01C974AD.DF49CDD0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
I noticed this too a while ago. I thought it was me doing something wrong
and set the value myself.
Kevin Roche
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I noticed this too a while ago. I thought it was me doing =
something
wrong and set the value myself.<o:p></o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Kevin Roche<o:p></o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>
<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> transf...@googlegroups.com
[mailto:transf...@googlegroups.com] <b>On Behalf Of </b>Matt =
Quackenbush<br>
<b>Sent:</b> 12 January 2009 01:05<br>
<b>To:</b> transf...@googlegroups.com<br>
<b>Subject:</b> [transfer-dev] Re: Nullable Values - still don't get =
it<o:p></o:p></span></p>
</div>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>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.<br>
<br>
<o:p></o:p></p>
<div>
<p class=3DMsoNormal>On Sun, Jan 11, 2009 at 2:23 PM, Jon Messer =
wrote:<o:p></o:p></p>
<p class=3DMsoNormal>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). <br>
<br>
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.<br>
<br>
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.<br>
<br>
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... <br>
<br>
Just my opinion though, and I'm sure there are people that would =
naturally
expect a date property to default to now()...<o:p></o:p></p>
</div>
<p class=3DMsoNormal><br>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
Before posting questions to the group please read: <br>
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-qu... =
<o:p></o:p></p>
<p style=3D'margin-bottom:12.0pt'>You received this message because you =
are
subscribed to the Google Groups "transfer-dev" group. <br>
To post to this group, send email to transf...@googlegroups.com <br>
To unsubscribe from this group, send email to
transfer-dev...@googlegroups.com <br>
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=3Den<br>
-~----------~----~----~----~------~----~------~--~---<o:p></o:p></p>
</div>
</body>
</html>
------=_NextPart_000_0D01_01C974AD.DF49CDD0--
Jamie Jackson
Jan 12, 2009, 9:44:03 AM1/12/09
to transf...@googlegroups.com
I brought this up recently too.
(http://groups.google.com/group/transfer-dev/browse_thread/thread/ecc7004e953fb43e?hl=en#)
I also think null dates should end up as null dates, and that null
numerics should end up as nulls as well. But as Mark said, something
configurable that could do the same would be great.
Something else funny that happens with NULL dates is that the "NULL"
value that Transfer returns is a coldfusion.runtime.OleDateTime,
whereas non-null dates are returned as Strings. This behavior seems
inconsistent, and it threw me for a loop when I was trying to debug
why one date (NULL) serialized to Flex, and another (concrete date)
failed to serialize properly.
Jamie
(http://groups.google.com/group/transfer-dev/browse_thread/thread/ecc7004e953fb43e?hl=en#)
I also think null dates should end up as null dates, and that null
numerics should end up as nulls as well. But as Mark said, something
configurable that could do the same would be great.
Something else funny that happens with NULL dates is that the "NULL"
value that Transfer returns is a coldfusion.runtime.OleDateTime,
whereas non-null dates are returned as Strings. This behavior seems
inconsistent, and it threw me for a loop when I was trying to debug
why one date (NULL) serialized to Flex, and another (concrete date)
failed to serialize properly.
Jamie
Reply all
Reply to author
Forward
0 new messages