On 7/30/07, Paul Johnston <[EMAIL PROTECTED]> wrote: > Sanjay, > > Yes, please do create a ticket for this. I think the changes are > sufficiently backwards compatible that not much (or hopefully, nothing) will > break. However, we'll want to be careful that we're encouraging people to > use the new approaches.
Sorry to say that this isn't true at the moment. Depending on the project, there is potential for quite a lot of breakage. The current situation is that all assign_mapper methods are gone from the class to a query attribute. It means no more MyClass.filter_by becomes MyClass.query.filter_by and so on... What's worse (from an upgrade point of view) is that many query methods are also deprecated (though still present in 0.4), namely get_by, select, select_by, etc... Most of these should be replaced by a filter_by() call. For example, MyClass.get_by(name="test") would become MyClass.query.filter_by(name="test").first() The reason of this change is that all non-generative query methods are gone in favor of the generative ones. This also rationalize the query process. Now all "result" filtering happens either through filter or filter_by. Some of you might ask: what about Elixir? [For those who don't know me, I'm one of its authors]. The current idea is to move the same path as SQLAlchemy. But I take the opportunity of this email to ask you what you think about it. If demand is strong enough, we might leave some of those methods on the class itself instead of moving them to a query attribute. -- Gaëtan de Menten http://openhex.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
