Thank you for your reply.

I'm not exactly sure of what is blocking the insert. I would say
SqlAlchemy, because my Foreign Keys are nullable (which raises the
question of whether it's a good design or not... but that's a
different story)

I read in the documentation:
http://www.sqlalchemy.org/docs/orm/relationships.html

" if an item of the child’s type is detached from its parent, mark it
for deletion"

Is there a way of put (or add) the parent "manually" in a child? I
believe that might work, because the parent is going to be merged,
flushed, commited and... written in the database when I start loading
the child

Again, thank you

2011/12/10 Michael Bayer <mike...@zzzcomputing.com>:
>
> On Dec 10, 2011, at 7:07 PM, Hector Blanco wrote:
>
>>
>>
>> That data (is JSON) is sent to the Category "handler". That handler
>> does the following
>> 1) Creates a new Category() instance,
>> 2) Fill the non-relationship fields ("_name" in this case)
>> 3) Adds the category to the session, so it gets an _id
>> 4) Go through the relationships fields ("_products")
>> 5) If there's a dictionary inside, call recursively to the same method
>> with that dictionary.
>> 6) The recursive call will try to create a new product (with the
>> proper "_model") and TRIES to add it to the database
>> 7) The recursive call returns, so that newly created product can be
>> added to the "_products" relationship of the category and the backref
>> will properly set up the "_category" relationship in the product
>>
>> And in the 6th point is where my problem shows up: If I set up the
>> delete-orphans, the database detects that I'm trying to insert a
>> product that doesn't belong to a category, therefore, it's orphan...
>> and blows up.
>>
>> Is there a way to delay the triggering of the "delete-orphans" or...
>> or something similar, so I can have a product not belonging to a
>> category... for a bit (until the category has finished loading?)
>
> when you say "the database detects" it's not entirely clear what you mean; 
> SQLA 0.6 and earlier will prevent you from persisting a "delete-orphan" 
> without a parent, before it ever goes to the database.  So that's SQLA 
> preventing the operation, not the DB.  OTOH if your foreign key is NOT NULL 
> then the DB prevents the orphan row from being INSERTed no matter what SQLA 
> allows or not.
>
> So it depends on specifically what is blocking the activity from happening - 
> if you want to INSERT rows with a null foreign key and still have 
> delete-orphan, you'd need to use SQLAlchemy 0.7 which removes the "orphan" 
> detection at the INSERT level.    If you don't want to actually have any 
> "orphaned" rows in the DB ever and the FK will be NOT NULL, then you have to 
> organize your steps such that the INSERTs don't occur until everything is 
> ready to go in - that's regardless of SQLAlchemy version.  Nothing regarding 
> orphans happens in any case until a flush occurs.   So if its a simple matter 
> of delaying the flush, just turn off autoflush temporarily.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to sqlalchemy@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 sqlalchemy@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