Cool, I like this use case :) Explains the need very clearly. On Nov 7, 2012, at 6:10 PM, John Huss <[email protected]> wrote:
> 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 >>> >> >>
