Setting INITIALLY DEFERRED and DEFERRABLE seems to work (now).
Thanks!
Jeff
On May 21, 2006, at 12:12 PM, Jeff de Vries wrote:
Going back and looking at my code, I see that a two step commit is
fine in this particular case since the initially committed items
can stand on their own without any inconsistencies. I'll try
setting the INITIALLY DEFERRED and DEFERRABLE constraints anyway to
see what happens.
Andrus Adamchik wrote:
Cayenne handles correct ordering of operations automatically,
based on dependencies derived from relationships.The algorithm has
a few limitations though. It can't handle cycles (when Entity A
depends on Entity B, but also Entity B depends on Entity A). This
probably also includes entities that have relationships to the
same entity (I assume this is the case the original post was
referring to).
There are few solutions:
1. (a workaround, rather than a solution) Do commit in two steps.
2. Define FK constraints in question as DEFERRABLE and INITIALLY
DEFERRED (supported by Postgres 8.*)
3. Set a custom org.objectstyle.cayenne.map.EntitySorter on the
DataNode.
Andrus
On May 20, 2006, at 3:00 AM, Marcin Skladaniec wrote:
Hm. Strange. I do really complex commits, sometimes 7 or more
related records (I mean 7 levels of relationship, not seven
entities), related by many-to-many many-to-one relationships and
never get those problems. And it doesn't matter if the records
are new or old. Could you describe how you are creating objects
and how do you commit them ?
Regards
Marcin
On 20/05/2006, at 4:31 PM, Tomi NA wrote:
On 5/20/06, Jeff de Vries <[EMAIL PROTECTED]> wrote:
I don't know if it is related or not, but I've also had
problems in the
past when I try to create a new parent and several child
objects related
to that parent all at once and then try to commit. The problem
looks
like Cayenne is INSERTing the child records into the database
first,
before the parent record, and the database complains that the
children
have an invalid foreign key (and, yes, I have the ON UPDATE and ON
DELETE rules for the foreign key set to DO NOTHING and I still
get the
error from PostgreSQL). To get around it I just committed the
parent
first, then committed all the children.
I had the same problem, IIRC: I was very surprised that cayenne
couldn't handle such a commit, although truth be told, I can't
imagine
everything that's going on under the hood of the operation that
would
make implementing this feature difficult.
I would certainly love to see this fixed (if at all possible) as I
wasn't to happy to have to commit in the middle of what had to
be an
atomic transaction. It'd also make the framework a lot more
flexible,
e.g. enabling the user to have long inter-commit sessions with
complex
data updates, if the user so desires.
t.n.a.
