i should correct myself; technically, if you didnt have the "save-
update" cascade, and your AccountActivity record were not present in
the session when you did the flush(), the row would also not be
updated. though im not sure if that will totally work right now.
i think if you specify the
so youd like to leave a row in "account_activity", containing the
primary key identity of a row in "account" which was deleted ?
this is not an issue of cacade from the ORM perspective, the "keeping
referential integrity" is a separate feature...theres a
DependencyProcessor that keeps the re
Hi Michael,
On Sun, 2006-09-03 at 10:58 -0400, Michael Bayer wrote:
> child records in a relationship are only deleted when the "delete" cascade
> rule is set (which is roughly equivalent to the old "private=True" flag).
>
> if the parent record is deleted without the "delete" cascade rule (the
>
child records in a relationship are only deleted when the "delete" cascade
rule is set (which is roughly equivalent to the old "private=True" flag).
if the parent record is deleted without the "delete" cascade rule (the
default cascade is only "save-update"), then the foreign key column in the
ch
A follow on question I have is if the relationship is specified
this way can you prevent the deletion of the activity
records when the account record is deleted?
On Sat, 2006-09-02 at 11:25 -0400, Michael Bayer wrote:
> since your AccountActivity does have an actual relationship to the Account
> t
since your AccountActivity does have an actual relationship to the Account
table, then yes, to go totally ORM would imply that youd have a relation
on the Account mapping.
mapper(Account, accounts, properties={
'activity':relation(AccountActivity, lazy=True)
}
)
mapper(AccountAct
6 matches
Mail list logo
