Cool, I like this use case :) Explains the need very clearly.
On Nov 7, 2012, at 6:10 PM, John Huss 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 th
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
Well, don't make any efforts on my behalf just yet. If it had just
been that one thing, I could have started the work myself :-)
The other blocker is true vertical inheritance support, and right now,
there is no imminent urge to switch by project management.
I just wanted to throw out a typical
On Nov 7, 2012, at 4:52 PM, Mike Kienenberger wrote:
>> Would be great if someone could share their typical use cases.
>
> We are not using Cayenne but JPA in my current project, but one of the
> items that we would need to address to convert from JPA to Cayenne is
> that we flush financial tra
On Wed, Nov 7, 2012 at 2:41 AM, Andrus Adamchik wrote:
> 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 agains
Another case to consider is what is expected when following relations. For
artist.getPaintings()... should we include the painting which is currently
being created? Consistency is important.
Use cases are simple. Imagine a view where you show a user's widgets. They
might be mailing list subscr
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
Aleksey V. Katorgin gmail.com> writes:
Thanks for reply!
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
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 wrote:
>
> On Nov 6, 2012, at 11:58 PM, Aristedes Maniatis wrote:
>
> > Andrus, I wonder
On Nov 6, 2012, at 11:58 PM, Aristedes Maniatis 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
On 7/11/12 12:55am, Aleksey V. Katorgin wrote:
Hi! Sry for my English.
Is this normal, that the objects with NEW state (not committed yet) are not
returned by performQuery method?
I have an scenario in my project where some entities are updated and some
entities are created but not committed (b
>
> Hi! Sry for my English.
No worries. Your message is very is clear.
> Is this normal, that the objects with NEW state (not committed yet) are not
> returned by performQuery method?
Correct, performQuery only returns objects from DB. So this is expected, and
you will have to deal with NEW ob
13 matches
Mail list logo
