Agreed - should be possible to do it for SelectQuery, as it is essentially a single-entity filter. Will require closer look at Expression.filterObjects(..) to make sure it works for to-many, etc…
And yes - some decisions are needed on how to handle uncommitted modified and deleted objects. It is hard for me to judge what's the best approach with those, as honestly I've never had a scenario where I would care to fetch against uncommitted objects. Would be great if someone could share their typical use cases. Andrus On Nov 7, 2012, at 2:48 AM, Aristedes Maniatis <[email protected]> wrote: > Yes, that's what I was thinking. As you say, should be easy to implement for > the SelectQuery case. It would: > > * Remove objects in the context which no longer match the query > * Add additional objects from the context (either new or edited) which match > the query > > It would either throw an exception or fail silently if the query was unable > to be evaluated in memory. Not sure which is better. > > Ari > > On 7/11/12 8:43am, John Huss wrote: >> You could just support SelectQuery fairly easily though, couldn't you? >> Project Wonder has this - you can do >> fetchSpec.setIncludeEditingContextChanges(true). >> >> >> On Tue, Nov 6, 2012 at 3:22 PM, Andrus Adamchik >> <[email protected]>wrote: >> >>> >>> On Nov 6, 2012, at 11:58 PM, Aristedes Maniatis <[email protected]> wrote: >>> >>>> Andrus, I wonder if there is some way to make this common use case >>> easier? >>> >>> The only way is to implement full in-memory query evaluation. >>> >>> Andrus >>> >>> >> > > -- > --------------------------> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
