synonyms had a lot of regressions in 0.7.2, and I worked onsite with a very
prominent user of SQLAlchemy to fix all known synonym regressions in 0.7.3 -
they use synonyms enormously, in all kinds of ways I never envisioned or
tested. If there are *any* incompatibilities whatsoever, I need full
reproducing test cases. There are no plans to ever remove synonym() or to have
any backwards incompatibilities of any kind.
Here's one particular order_by(), the one on Query which is most common. Works
fine:
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
Base= declarative_base()
class A(Base):
__tablename__ = "a"
id = Column(Integer, primary_key=True)
b = Column(Integer)
c = synonym("b")
s = Session()
print s.query(A).order_by(A.c)
You might be using a different order_by (like on relationship, etc), or you
might have a different flavor of synonym. So need a full reproducing test
case as a trac ticket please thanks !
On Dec 11, 2011, at 12:52 AM, Hector Blanco wrote:
> I would like to. I've been testing 0.7.4, and it seems to work really
> fast, but my code is heavily dependent on Synonyms, which seem to be
> incompatible with certain new features (I'm getting errors when I use
> order_by, for instance) so, until I have time to migrate my code to
> Hibrids, I'm afraid I have to stick with SqlAlchemy < 0.7
>
> One of these days, though...
>
> Thanks again!
>
> 2011/12/11 Michael Bayer <mike...@zzzcomputing.com>:
>> if you have a relationship() with delete-orphan, SQLAlchemy will not let you
>> save the child without the parent being attached. It is more or less a bug
>> in that this particular check is unnecessary, and you should upgrade to 0.7.
>>
>>
>> On Dec 11, 2011, at 12:00 AM, Hector Blanco wrote:
>>
>>> 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.
>>>
>>
>> --
>> 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.
>
--
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.
