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 ?
------------------------------------------------------- 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
