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.