> For now, shouldn't something like this work (though it seems to be an
> unnecessary performance waste)..
>
> Artist localArtist = (Artist)DataObjectUtils.objectForPK(context,
> artist.getObjectId())
This should work, but an "appropriate" way is to transfer an object to
a local DataContext before using it in the expression:
http://objectstyle.org/cayenne/userguide/datactxt/moving-objects.html
BTW, DataContext.localObjects() is smart enough to check if the object
is already in this DataContext, so you can use this method without any
extra "if" statements to determine if this operation is needed.
Andrus
On Oct 9, 2004, at 8:37 PM, Cris Daniluk wrote:
> Ahh. In this case, the object is in fact coming from a different
> DataContext. The problem is that it is being passed through a
> delegate... In
> my test environment, both sides are running in the same VM, however
> that
> won't necessarily be the case in production. Is there an "appropriate
> way"
> to work around this? Assuming two objects are in a consistent state,
> they
> really are the same, even though they're not the "same"...
>
> For now, shouldn't something like this work (though it seems to be an
> unnecessary performance waste)..
>
> Artist localArtist = (Artist)DataObjectUtils.objectForPK(context,
> artist.getObjectId())
>
> Thanks,
>
> Cris
>
>> Cris,
>>
>> I got the details of your original post wrong... Needed more coffee...
>> Thanks for pointing this out. Anyway, the rules of uniquing
>> still apply here. I wrote a little test case that shows that
>> if a "filterObj" is in the same DataContext, filtering on a
>> relationship works. Let me know if I am answering the wrong
>> question again ;-)
>>
>> ....
>> Artist filterObj = (Artist)
>> DataObjectUtils.objectForPK(context, Artist.class, 33018);
>> Expression exp = Expression.fromString("toArtist = $artist");
>>
>> List paintings = context.performQuery(new
>> SelectQuery(Painting.class));
>> List filtered = exp
>> .expWithParameters(Collections.singletonMap("artist",
>> filterObj))
>> .filterObjects(paintings);
>>
>> assertEquals(1, filtered.size());
>> assertEquals("P_artist18", ((Painting)
>> filtered.get(0)).getPaintingTitle());
>>
>> What happens here is that all artists related to fetched
>> paintings are HOLLOW, except for this one that already exists
>> in the DataContext before the fetch. So 'filterObjects' works
>> as expected. In your example you do not show anywhere how you
>> obtain "filterObj" - you need to make sure it is in the same
>> DataContext as the one you are using in query.
>>
>> Hope this helps.
>>
>> Andrus
>>
>>
>> On Oct 9, 2004, at 2:38 PM, Cris Daniluk wrote:
>>> Andrus,
>>>
>>> Thanks for the response. To clarify, it is not my filterObj that is
>>> HOLLOW - in fact it is COMMITTED. It is the object that Cayenne is
>>> comparing against in the Expression.filterObjects that is HOLLOW.
>>> Thus, of course, they are guaranteed not to be equal.
>>>
>>> If I take the same expression query but instead make it on an
>>> attribute, it works because Cayenne is forced to "inflate"
>> the HOLLOW
>>> object as you stated..
>>>
>>> Expression qual =
>>> Expression.fromString("toDomainObject.attribute=$attr");
>>> return (RefJurisdictionInLang) qual.expWithParameters(params).
>>> filterObjects(context.performQuery(q)).get(0);
>>>
>>> This works fine.
>>>
>>> Basically, if I'm comparing directly against the ObjEntity, Cayenne
>>> never inflates the object in filterObjects.
>>>
>>> Cris
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Sat Oct 09 2004 - 22:16:39 EDT