It has been a few years since I last looked at Ashwood, but I believe you are right about #1. If I recall, the graph is pre-generated once and reused after that, therefore no PK considerations are involved, only Entity relationships.
I hadn't thought of having an option to turn off Ashwood completely. That would require the DB to only use deferrable constraints, but could be a quite useful feature. On Thu, Dec 10, 2015 at 7:26 AM, Andrus Adamchik <and...@objectstyle.org> wrote: > > > On Dec 10, 2015, at 3:13 PM, Michael Gentry <mgen...@masslight.net> > wrote: > > > > I didn't understand your #1 example. > > "A1 depends on B1 depends on A2" <- no cycle > > when mapped to entities becomes this: > > "EntityA depends on EntityB depends on EntityA" <- IIRC that will be > treated as an unresolvable cycle by Ashwood. > > > #3 I'm pretty sure can be done with deferrable constraints (such as > > PostgreSQL supports) if you assign the keys up-front. The mandatory FK > > won't be checked until the transaction is committed. I know in the past > > I've had to make several schema design changes due to limitations in > MySQL > > (and sometimes Cayenne) because of constraints/etc. There will simply be > > some cases that aren't easily solved by Cayenne due to other external > > choices, and that's OK -- we shouldn't try to solve those. But > > pre-assigning the PKs if using sequences or auto-PK support might be > > trivial enough for us to do and, if your DB supports deferrable > > constraints, solve a few of those issues. > > This won't work with auto-incremented PK of course. But any other current > Cayenne PK generation strategy (sequences, PK table lookup) should work > with deferred constraints as Cayenne does generate all PKs before commit. > The only thing we need is to turn on deferred constraints (and maybe turn > off Ashwood, as in this case Cayenne-side operation ordering will be a > waste). > > Andrus > >
