I've attached a patch which fixes this, in case anyone is
interested. Because we do this initialization in the template I think
there will be extremely little overhead (since we know ahead of time
which relationships are toMany). What do the rest of you think?
Gili
Mike Kienenberger wrote:
> Moving this to dev.
>
> Actually, I wonder if the behavior is consistent even between NEW and
> other objects in other states.
>
> I'm thinking a toMany relationship will always return null if the
> relationship hasn't been initialized, regardless of whether the DO is
> registered or not.
>
> So null really means that the object's toMany relationship hasn't been
> initialized, and maybe that's a bad way to handle it since the methods
> are "add/remove/get" rather than "set/get"
>
> On 9/8/05, Mike Kienenberger <mkienen..mail.com> wrote:
>
>>I'd be "-0" on a patch for this.
>>
>>It'd add overhead because each DataObject would have to iterate over
>>the ObjEntity's attributes to determine if the value should be set to
>>EMPTY_LIST.
>>
>>Since I almost never work with DOs outside of a DataContext, I have no
>>issues with the DO returning null in those cases, and I consider it
>>useful to throw an error if I try to read a toMany relationship from
>>an unregistered object.
>>
>>On the other hand, if people who actually perform a lot of work on
>>unregistered objects think this makes sense, I have no compelling
>>reasons against it, either. I can understand the claim that the
>>behavior isn't consistent between registered and unregistered objects.
>>
>>On 9/8/05, Gili <cowwo..bs.darktech.org> wrote:
>>
>>> That is possible. As far as I can tell, referencing
>>>Collections.EMPTY_LIST consumes as much resources as pointing to null.
>>>Is there any reason we don't initialize delegates' lists to
>>>Collections.EMPTY_LIST? I could contribute a patch if necessary, but
>>>does this sound reasonable to everyone?
>>>
>>>Gili
>>>
>>>Eric Schneider wrote:
>>>
>>>>Gili,
>>>>
>>>>Sounds like the object was never registered, or somehow it's
>>>>persistence state is transient. Normally, toMany relationships will
>>>>always return an empty List if there are no related objects.
>>>>
>>>>Eric
>>>>
>>>>On Sep 7, 2005, at 4:02 PM, Gili wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>> I'm expecting a toMany relationship to return an empty list if
>>>>>empty and it seems to return null. Is this by design (I can't seem to
>>>>>find it documented anywhere). Does this mean I have to check for both
>>>>>null or an empty list everywhere in my code or is there an easier way?
>>>>>
>>>>>Thanks,
>>>>>Gili
>>>>>--
>>>>>http://www.desktopbeautifier.com/
>>>>>
>>>>
>>>>
>>>--
>>>http://www.desktopbeautifier.com/
>>>
>>
>
-- http://www.desktopbeautifier.com/
Index: cayenne/src/cayenne/resources/dotemplates/superclass.vm =================================================================== RCS file: /cvsroot/cayenne/cayenne/src/cayenne/resources/dotemplates/superclass.vm,v retrieving revision 1.10 diff -u -r1.10 superclass.vm --- cayenne/src/cayenne/resources/dotemplates/superclass.vm 20 Nov 2004 19:51:09 -0000 1.10 +++ cayenne/src/cayenne/resources/dotemplates/superclass.vm 8 Sep 2005 17:15:45 -0000 ..-3,6 +3,7 @@ #end #if( ${classGen.isContainingListProperties()} ) +import java.util.Collections; import java.util.List; #end ..-13,6 +14,15 @@ */ public class ${classGen.superPrefix}${classGen.className} extends $classGen.superClassName { +## Create constructor + public ${classGen.superPrefix}${classGen.className}() { +#foreach( $rel in ${classGen.Entity.DeclaredRelationships} ) +#if( $rel.ToMany ) + writeProperty("${rel.Name}", Collections.EMPTY_LIST); +#end +#end + } + ## Create property names #foreach( $attr in ${classGen.Entity.DeclaredAttributes} ) #set( $classGen.Prop = $attr.Name )## let controller know about current property
This archive was generated by hypermail 2.0.0 : Thu Sep 08 2005 - 13:28:53 EDT