kwarg wrote:
> It's not just a single flag - it's a flag on a "particular" side of
> the relationship
> and in conjunction with "appropriate" set of cascade parameters that's
> suitable
> for my case.

It's on the side of the relationship that manages the parent-child nature
of the foreign key, where "parent" means the source of the referenced
value.   While an ORM like hibernate tends to place the management of the
foreign key on the child-parent side (i.e. the many-to-one end), it makes
less sense that it could be on "either" side and that would certainly be
much more confusing.  Whichever side it goes on, there's always some
brain-flippy confusion that incurs from some of the settings.   In SQLAs
case having it on "parent" lends greater weight to the cascade options
like "delete, delete-orphan" which are events that begin with the parent
and extend to the child (though I think hibernate places those options on
the parent side too).

Now as far as, "I want to set up relation(... backref=foo)" and I don't
really understand which side does what", I don't think there's any way
around having to understand the basic nature of how relation()/backref
work, and that applies to any ORM.  There's plenty of docs and examples
and we can add more if needed.



>
> On Dec 7, 11:14 am, Michael Bayer <mike...@zzzcomputing.com> wrote:
>> On Dec 7, 10:02 am, kwarg <ekozh...@gmail.com> wrote:
>>
>> > Thanks, bojanb.
>> > The patch kinda worked - after some trying I guessed the magic
>> > combination of cascade,passive_deletes
>> > and bakref placement on one instance. But it doesn't work on other
>> > relationship - looks like I'd have to play
>> > try-fail-guess game again.
>> > To the authors of SQLAlchemy - why is it so difficult to make it do
>> > such a simple thing - DO NOTHING???
>>
>> im sorry, can you expound upon how specifying a single flag of
>> "passive_deletes='all'" is difficult ?
>>
>>
>>
>>
>>
>> > On Nov 17, 11:14 am, bojanb <boj...@gmail.com> wrote:
>>
>> > > You probably want to add passive_deletes='all' to the above
>> relation.
>>
>> > > Be sure to put it into the right side of the relation (e.g. if
>> you're
>> > > defining the relation in B's mapper put it there, but if you're
>> > > defining it in A's mapper put it in the backref).
>> Seehttp://groups.google.com/group/sqlalchemy/browse_thread/thread/3a2842....
>>
>> > > On Nov 17, 4:43 pm, kwarg <ekozh...@gmail.com> wrote:
>>
>> > > > I have a one-to-many object relation, A-to-B.
>> > > > When an instance of A with several Bs is created it needs to be
>> > > > persisted by SQLAlchemy. I have that via save-update rule. But
>> when I
>> > > > delete an A I DON'T WANT SQLAlchemy to do anything to its Bs -
>> it's
>> > > > taken care of by foreign key constraints in the DB. Instead it
>> deletes
>> > > > them explicitly if there's a delete cascade rule or tries to
>> nullify
>> > > > Bs' FK fields for any other cascade rule combination.- Hide quoted
>> text -
>>
>> > > - Show quoted text -- Hide quoted text -
>>
>> - Show quoted text -
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
>
>

--

You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.


Reply via email to