On Feb 23, 2006, at 12:06 AM, Michael Bayer wrote:
On Feb 22, 2006, at 11:47 PM, Daniel Miller wrote:
The more I think about it the more I lean toward having it removed
from the parent collection after the child is deleted (when the
session is committed, not before).
yah its just a pretty big monkeywrench to throw in...a commit()
operation currently doesnt change any datastructures at all, just
writes to the database. when you say we're going to automatically
modify collections *within* the commit, it starts to get
crazy....what about backrefs firing off, various setter/getter
handlers firing off and changing more things ? it can really blow
up a commit. maybe thats what theyre getting at with hibernate.
im really not so psyched to maintain a backwards reference of every
list an object is attached to, just so we can raise an exception
when someone goes to delete(). I was hoping to keep the whole
"attributes" idea pretty sparse since the main purpose of SA is SQL
generation, not an in-memory referential integrity engine. it
would be easiest to just check lists for deleted objects when the
list itself is being saved and throw an exception at that point,
instead of against any possible list at the point of delete. can
we identify specific scenarios that might justify the extra
overhead and complexity ?
That sounds OK to only raise the exception if the list is being
saved. One other item though, I don't believe Hibernate adds items to
collections automatically (unlike SA). From the SA documentation on
backreferences:
# attach u to a2
a2.user = u
# the bi-directional relation is maintained
>>> u.addresses == [a1, a2]
True
Hibernate does not do that. It would require something like this:
a2.user = u
>>> a2 in u.addresses
False
u.addresses.append(a2)
>>> a2 in u.addresses
True
What I'm saying is, since you're using the backref to automatically
add an item to a collection can you use the backref to automatically
remove the item when it's deleted?
Hibernate has a bunch of cascade types that control the exact
behavior of relationships between entities. In general I find their
approach to be very flexible and very confusing (at least at first)...
~ Daniel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users