A use-case for us is this: We do a bulk import of flat files(CSV). We import rows for the Parent table and then rows for the Child table. The Child rows have to be linked to the Parent rows and this is done by querying the Parents for a row matching an ID column in the Child. If the Parent rows have not been committed before this then there will be no matches. Sometimes you can just commit the Parent table first, but t's not always safe or desirable. So you end up creating your own little in-memory cache.
On Wed, Nov 7, 2012 at 1:41 AM, Andrus Adamchik <[email protected]>wrote: > 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 > > > >
