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/
>
This archive was generated by hypermail 2.0.0 : Thu Sep 08 2005 - 13:11:47 EDT