On 09/23/2016 10:46 AM, Torsten Landschoff wrote:
On Thursday, August 25, 2016 at 3:57:30 PM UTC+2, Mike Bayer wrote:
that perspective this is not much of a "DependencyProcessor" problem
because you have this local attribute that just contains a view
(comma-separated-list of keys) of a collection attribute on the same
object. That is, I don't see much of a "topological" problem here if
How is this different from updating a column that contains the foreign
key referring to another object (which is taken care of by a
DependencyProcessor afaict)?
because a foreign key is a constraint that will enforce what you place
there has to exist elsewhere, or in the delete direction, must be erased
before the dependee value is erased. additionally, an FK-referencing
column may be NOT NULL which makes it such that we can't even insert the
row without the referred value being present. If the column is
nullable, the unit of work is still trying to not have to go and do a
second UPDATE for a row once we get the PK value we're to refer to
(although the post_update feature causes it to do exactly that, as there
are some scenarios where this is necessary).
on a database like SQLite without referential integrity and in the
absense of NOT NULL constraints, we could just roll through all the
objects, insert all the rows in any old order, and then just emit UPDATE
statements for whatever primary key values we didn't have yet.
the DependencyProcessor model could certainly work for your case, it's
just that the current objects aren't currently worked out to be easily
extensible in userland (or perhaps it's not that hard, it's just not a
use case that we have set up for support as of yet). There are other
ways to get at the "creases" of the unit of work, namely in events like
after_insert / after_update and before_delete, though currently there's
only limited support for setting up new kinds of inter-object
dependencies that would affect the order of operations in absense of
traditional relationships.
This sort of extensibility is definitely possible it just would require
lots of upfront planning so that it doesn't become a burdensome plugin
architecture that nobody ever uses. We have one of those already, in
sqlalchemy.ext.instrumentation. I took on the significant task a few
releases ago of extricating this huge amount of complexity from the
middle of the ORM out to an extension module where it no longer needs to
be dealt with in order to understand the class instrumentation.
Avoiding that kind of situation in the first place is the goal.
I'm understanding correctly. Copy-on-write is done by an attribute
event, object is written therefore we set a flag, in before_flush() we
copy all the objects that need to be copied-on-write, then I think you
have the after_flush there to update the parent object. you can set
up Bundle.members there also.
Actually the objects (which are mapped) are already copied beforehand so
when flush is called I have a bunch of new objects which don't have any
primary key yet.
Anyway, I seem unable to express myself so please do not spend more time
on this. The current solution is working fine albeit slightly inefficient.
Thanks and Greetings, Torsten
--
You received this message because you are subscribed to the Google
Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
