Oh, it wasn't exactly an error with the Synonyms itself. They are
working fine for what I've been doing with them (just using them for
getters/setters... nothing fancy) It was more that when I migrated the
Synonyms I have in the 0.6.8 to hybrid_properties in 0.7.4, I was
getting trouble (which I'm not anymore:
http://groups.google.com/group/sqlalchemy/browse_thread/thread/23c0cfa1d4789ee5)
2011/12/11, Michael Bayer <mike...@zzzcomputing.com>:
> 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.
>
>
--
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.
