Michael Bayer wrote: > ok let me rephrase that... i have concerns. i think the concerns could > be addressed, and we might be able to add this kind of feature...but i > dont want to rush into it singlehandedly.
I won't blame you for that. I'll help out as much as possible given my busy schedule. > heres the things that should > be resolved: > > - we add non-column properties to SomeClass.c. people will get > confused that SomeClass.c has a bunch of stuff on it that mytable.c > does not. do we change the name of 'c' ? Part of me say adding extra columns to SomeClass.c wouldn't be so confusing, and would actually be intuitive. For example in the original question that started this thread it seemed logical to me that 'order' should have been in there since it was a mapper property. Sure maybe it's a bit more than meets the eye at first, but I think it's very logical to have mapper properties in SomeClass.c but not have them in table.c. As long as it's well documented I don't think it would be a problem. The only other thing I can think of is to create a function that would return a "cols" object. In the spirit of python's getattr() function: from sqlalchemy.orm import getcols c = getcols(SomeClass) session.query(SomeClass).select(c.order == order) I often find myself assigning SomeClass.c to a local variable when I'm building a query anyway. It prevents excess verbosity. > > - people will say things like, SomeClass.c.order > order. how do we > interpret that ? esp. for composite foreign keys. I assume you're implicitly asking about the choice to use AND or OR to combine multiple comparisons of a composite key. For example (assume Order and SomeClass are related by user_id and quote_id): # given this order = Order(user_id=4, quote_id=5) session.query(SomeClass).select(SomeClass.c.order > order) -- Do we generate this? WHERE some_class.user_id > 4 AND some_class.quote_id > 5 -- or this? WHERE some_class.user_id > 4 OR some_class.quote_id > 5 I don't think the <, <=, >, and >= operators would be very useful on most relationship comparisons; especially those with composite keys. However, the == and != operators are obviously useful in many cases. It's like comparing user-defined Python objects without explicit __gt__ and __lt__ implementations. Python 2.x compares the id() of the objects, while Python 3000 will raise a TypeError (I think that's the right error). The reasoning behind this decision[0] is that unless there is an explicit ordering for a given pair of objects, it doesn't make sense to compare them using the inequality operators. At any rate, I would recommend not implementing those comparison operations for relationships by default (at least not for multi-column relationships). If someone really needed them maybe they could create their own custom relationship subclass? [0] http://mail.python.org/pipermail/python-dev/2005-November/057925.html > > - is it really as simple as just producing the primary/foreign key > columns of both sides ? i fear that a whole class of patterns are > going to become apparent after adding that feature, and then people are > going to complain about SA being "broken" until an entire HQL-like > layer is added to implement all those features. maybe theyre going to > stick SomeClass.c.order into the order_by clause, theyre going to stick > it in func() calls, CAST calls, etc. and expecting all this magical > behavior. pretty much every other feature of SA proved to be a > gargantuan undertaking compared to how easy i thought it would be when > i first wrote it :) how would this feature be presented ? Could we implement it as simply as possible for now and see how it's used? As new use cases come up we can either extend the implementation or explain why they are not supported (i.e. too complicated, inconsistent with other parts of SA, etc.). > > - is this feature also going to figure out all the joins from class A > to B, if my query is based on class A and the criterion object is all > the way on B? the way select_by, join_to works ? that seems trickier > and i can see people expecting that behaivor as well. This is something I thought about immediately when I first imagined the idea. Personally, I don't really like the automagical join behavior because it's not explicit and can lead to obscure bugs that are hard to track down (why is this join suddenly returning the wrong results? ...hours later we discover that a new relationship was added that caused SA to pick a different relationship path for the join). The problem is that a seemingly unrelated (no pun intended) change can cause these magic joins to be interpreted differently. I tried to use that behavior once myself but quickly discarded it when SA used some other relationship path than the one I intended to use. In general I think it's best to require explicit relationship paths at all times and give useful errors when the given path can't be determined using those strict rules. > if we did get > that to work, should we then reconsider the whole "join_to", "join_via" > concept ? is it going to be confusing to have so many ways to build a > join ? Personally I don't like identifying relationships with strings as the join_to and join_via functions require. I'd rather do it with explicit objects that raise attribute errors when I make a typo. Here's a translation of the last example in the join_to/join_via docs[1]: q = session.query(User) c = getcols(User) q.select( (c.addresses.street == 'some address') & (c.orders.items.item_name == 'item #4') ) Notice how the relationship objects (i.e. c.addresses and c.orders) on 'c' contain all the columns/relationships of the related class. Also notice how this makes it very easy to specify an explicit relationship path. It makes it very concise, simple and intuitive to create complex joins. So yes, to answer your question, I think this would afford a much simpler way to create joins than join_to and join_via. However, I see no reason why those functions couldn't remain (although I'm not sure why you'd want to use them when you can use this syntax). [1] http://www.sqlalchemy.org/docs/datamapping.myt#datamapping_selectrelations_jointo ~ Daniel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
