Thanks for your time and information.  When I tried to create an
example that wasn't so badly convoluted, it worked fine which led me
to discover my problem.

Thanks again,
Kent

On Jul 8, 11:32 pm, Michael Bayer <[email protected]> wrote:
> On Jul 8, 2011, at 5:28 PM, Kent wrote:
>
> > Suppose I have a related collection that is *not* single_parent and
> > *not* cascade delete or delete_orphan.  (The reasons are poor
> > relational schema design, which I can't control.)
>
> > I would like to programatically delete records occasionally, but
> > session.delete(instance) throws "AssertionError: Dependency rule tried
> > to blank-out primary key column".
>
> > Because this is not single_parent, I do not want delete_orphan True.
>
> > How can I accomplish deleting this instance?
>
> So "dependency rule tried to blank out PK column" is one of those errors 
> where if SQLAlchemy left it out, you'd get an error at the SQL level instead 
> (assuming SQLA still nulls out the value).   Usually we just go for that 
> behavior, but for that error at some early point I felt we needed to say to 
> the user, no really, what you're doing here means you're going to set a PK to 
> NULL, we thought we'd might tell you sooner.
>
> If you have an object that relates to its parent via a foreign key that's on 
> its PK, hmm OK if that PK is composite then it could be a collection.   The 
> question would be what do you want to do with that child collection object, 
> if not delete it ?    If the parent is ID=5 and the child object has 
> composite PK (5, "foo") where the "5" is a foreign key, are you saying "5" 
> refers to some other row somewhere also ?
>
> I might need to see how you are relating the rows in this case.    Assuming 
> you're not using standard relational PK/FK types of rules though it may be 
> just a matter of setting passive_deletes="all" which is designed for the 
> "please don't touch the related column" use case.   Perhaps I rambled on too 
> long without just saying that, as we added that for those weird cases where 
> folks wanted the child row to remain unaffected.

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

Reply via email to