Wouldn't he need to configure the ondelete cascade for even
session.delete(session.query(User).get('testname')) to work that
way?
I know why the cascade is necessary for session.query(User).delete()
to also delete the associated IP instances. But I don't quite get why
it's not necessary for
SQLAlchemy cascades deletes to collections associated with objects that are
present in the Session. Not every database supports cascading of foreign
keys. I didn't introduce this concept in my last email, but if you
configure foreign key level cascades, and your application is only to be
use the passive_updates=True, passive_deletes='all' flags. These
are described at
http://www.sqlalchemy.org/docs/05/sqlalchemy_orm.html#docstrings_sqlalchemy.orm_modfunc_relation
.
On Dec 5, 2008, at 11:42 AM, James Brady wrote:
Hi all,
I'm trying to get deletes and updates cascaded
actually, use passive_deletes=True, not 'all'. It will issue DELETEs
only for collections that are already loaded, this doesn't break
anything and prevents unnecessary SELECTs of unloaded collections.
The True setting is needed so that the session can update the state of
those
Ah, I should say I'm using SA 0.4.3 - I going to try the same test on
0.5
On Dec 5, 11:36 am, Michael Bayer [EMAIL PROTECTED] wrote:
actually, use passive_deletes=True, not 'all'. It will issue DELETEs
only for collections that are already loaded, this doesn't break
anything and
Assuming user_id is a surrogate primary key, I dont see any need for
onupdate=CASCADE to be used here. Additionally, ondelete=CASCADE
on your hat.user_id column implies that hat will be deleted when a
user entry is deleted - however your relation has this set up on the
many-to-one side
Yep, the same behaviour in 0.5rc4
On Dec 5, 12:44 pm, James [EMAIL PROTECTED] wrote:
Ah, I should say I'm using SA 0.4.3 - I going to try the same test on
0.5
On Dec 5, 11:36 am, Michael Bayer [EMAIL PROTECTED] wrote:
actually, use passive_deletes=True, not 'all'. It will issue DELETEs
Ah! I see - I had the cascade and passive_delete arguments in the
wrong place.
This works as expected in 0.4.3 and 0.5 now.
Thanks for the help
James
On Dec 5, 12:47 pm, Michael Bayer [EMAIL PROTECTED] wrote:
Assuming user_id is a surrogate primary key, I dont see any need for
