On 6/2/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > On Jun 2, 2007, at 6:02 AM, Gaetan de Menten wrote: > > > Hmmm, after some more thoughts there is one little aspect of that > > which bothers me: once you joined to something, you can't add > > filtering criteria on the initial table/class. This is actually one of > > the features I disliked about the current code. It might be rare use > > case but I, for one, like to be able to construct queries in any > > order, so that I can factor out the common part and store it somewhere > > then add what is specific at a later point. Here, if the specific part > > is about the initial table, I'm screwed. Adding a method to just > > move/reset the joinpoint would solve this, though I find it ugly. > > Better than nothing though. > > > > This would look like this: > > > > q = session.query(User).join(['orders', 'items']).filter_by > > (item_name='foo'). > > user_query = q.join(['addresses']).filter_by > > (email_address='[EMAIL PROTECTED]').reset_joinpoint() > > > > users = user_query.filter_by(name='Foo').list() > > yeah i had that idea as well, and yeah its a little ugly. theres > also the possiblity of using join(None). > > let me summarize things that im thinking we do: > > - we want to go with the joinpoint concept here, where join() starts > from the beginning, and join(None)/reset_joinpoint brings it back.
I'd personally vote for join(None). Seem pretty logical if join starts from the beginning and doesn't introduce a new method (IMHO there are already too many of them on query objects). > join() is used to add a join and also modify the joinpoint of the > query, so that you can add more criterion using filter() or filter_by > () or others. I think this particuar tweak would probably even be OK > to put in the current trunk for release 0.3.8 unless people think its > going to create problems...the only backwards-incompatible change > being a join() starts from the beginning, not the previous join(). > > - i think filter_by(['list','of','properties'], **kwargs), i.e. an > optional, positional string/list-of-strings argument, should also be > present, and it will create the joins and criterion using table > aliases, and will not be related to joinpoint at all. apparently > django does this, and it would let us define criterion for multiple > overlapping paths, such as q.filter_by(['a', 'b, 'c'], d=x).filter_by > (['a', 'b', 'e'], d=x). thats something that you cant do with the > straight join() alone (but of course you can do with explicit aliases > and filter()/select_from()). That'd be pretty nice to have that alias feature, because in that case you could join several times to the same table through different relationships easily. > - the "auto find me a property" behavior is gone. not sure if I want > to remove it from select_by() and friends, i think it should probably > remain in those in a deprecated state. > > - ClauseElement support would be removed from filter_by(). you can > just use filter() for those. the older _by() methods, which i want > to deprecate, would be left alone for backwards compatibility. What do you replace order_by with? > - i want to deprecate all the criterion methods that are not filter, > i.e. all the selects and most of the gets (except straight get()). > selecting from a full statement we can do with query.from_statement > (<select statement>), the argument of which is a select() or a string. > > deprecating select() and select_by() is to create a single simple > interface to query based on the more flexible filter(). but it does > mean a bit more typing in many cases. I would hope everyone is OK > with that. I'd personally like this but that's probably because I don't use those much. But I think many people are using those so that might be an unpopular move. As such, it would probably deserve a thread on its own, so that people would actually have a chance to react... -- Gaëtan de Menten http://openhex.org --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
