[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
Cleaning out my inbox... FWIW I'm +1 on removing the old-style methods, +1 on .first instead of .scalar, +1 on adding .one, and +0 on renaming .list to .all. Did you make a decision for 0.4 Mike? -J --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On 6/12/07, Michael Bayer [EMAIL PROTECTED] wrote: we have, in fact, made a tip of the hat to SAT analogy questions (selecting everything is to all() as selecting just the first row is to: a. scalar() b. first() c. list()[0]). I've already said it earlier but since you didn't comment on that, maybe you didn't see my remark: shouldn't the non-generative aggregate methods be deprecated? I feek it would be much more coherent this way. -- 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote: - filter_by() would gain a new positional argument, which is optional, which is either a string or list of strings indicating property names, indicating a join path. when this argument is present, a self-contained join among those mapped properties will be generated, and the keyword criterion of the filter_by() would be expressed against the endpoint of that join. by self-contained, i mean that the tables used in the join will be *aliased* anonymously, so that different filter_by()s which specify join paths that overlap can be used together. the existing behavior of being able to say query.join(['x', 'y', 'z']).filter_by(**kwargs) remains as well (but is different in that it doesnt create aliases). ... - the new positional argument of filter_by() is based on Gaetan's idea, as well as some light that was shed on the IRC channel. it looks like this: session.query(User).filter_by(['orders', 'items', 'keywords'], keyword_name='foo').filter_by(['orders', 'items'], item_price=49.50).list() above, we have created two joins from the users table, one of which joins from 'orders' to 'items' to 'keywords', and the other from 'orders' to 'items'. the two sets of joins are constructed using anonymous aliases, so that you get all users who have purchased an item that has the 'foo' keyword, and have also purchased an item that costs 49.50. the two paths across 'orders' and 'items' are isolated from each other. if aliases were not used above, the redundant 'orders' and 'items' tables would converge into one FROM clause each in the final statement since thats the behavior of select(), but then the semantics of the query would then be all users who purchased items that cost 49.50 and also have the 'foo' keyword. the above capability is currently available by constructing your own Alias object and building join criterion manually. But it was pointed out on IRC that the Django ORM constructs filtering queries using aliases as above. for a lot of cases the approach saves a lot of lines of code spent creating manual aliases. Hi there, I like where things are going, but I think I should clarify how the Django ORM does things to my knowledge. The filter method in the Django ORM only supports keyword args a la filter_by. Every query is based off a mapped object (like Post). Each filter can access other tables' columns via the relations, using a construct like: .filter(jobtitle__content__txt__icontains = keyword, domain__str__content__txt__icontains = keyword) Both jobtitle and domain__str (the domain relation and then the str relation) are of a mapped object Strids type, which maps to the strids table. This has a relation content to a table with contains the actual text to use for the current locale. (__icontains is there to perform a LIKE '%keyword%', since there's no ClauseElement equivalent. I'm not suggesting supporting that.) The joined tables are aliased as the path from the base object. In this case, the jobtitle join is: INNER JOIN strids AS positionprofiles__jobtitle ON positionprofiles.jobtitleid = positionprofiles__jobtitle.id The domain__str__content join is: INNER JOIN dimensions AS positionprofiles__domain ON positionprofiles.domainid = positionprofiles__domain.id INNER JOIN strids AS positionprofiles__domain__str ON positionprofiles__domain.strid = positionprofiles__domain__str.id INNER JOIN content AS positionprofiles__domain__str__content ON positionprofiles__domain__str.id = positionprofiles__domain__str__content.strid ie, it joins on domain, then str, then content, giving each one an alias based on the path from the mapped object. I'm a little worried that using anonymous aliases will make some queries impossible. For example, if you want to list all purchases of product type B made by a manufacturer with a particular discount agreement, since one would require a filter_by(['product', 'store'], ...) and the other will require a filter_by(['product', 'type'], ...). In the Django ORM, since the path to 'product' is the same, it's the same join. Not being able to rejoin on the same path may make certain kinds of query building impossible. Then again, using anonymous aliases for each kind can solve different types of problems that can't be done without them. I think the principle of least astonishment would be to not have a new join for the exact same path. But, given enough documentation, one can avoid astonishment. I hope this made the situation clearer, and not more confusing. Neil -- Neil Blakey-Milner http://nxsy.org/ [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
all seems ok. and ORM will become looking less SQLish (as .select being the most SQLish word IMO) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
These sound like a good progression of the library. Would there be a way to turn on warnings if one were to use a deprecated interface? Or if the programmer wants to be even more strict, raise an exception? This wouldn't be the default, but rather an available option. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On Jun 3, 2007, at 10:33 PM, Michael Bayer wrote: one() raises an exception when theres not exactly one result, scalar () does not. currently we have selectfirst() and selectone(), people seem to like the dichotomy. [0] specifically adds LIMIT 1 OFFSET 0 to the query and i dont think scalar() or one() would do that (LIMIT is specifically a problem with DB's like Oracle that dont directly support it...more complex oracle queries cant handle it). scratch that partially, selectfirst() and selectone() *do* add the limit. however in the case of selectone(), it adds a limit of *two*. if a second row is present- exception. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
The use of scalar() here seems out of place with both the common CS usage of the word (e.g. scalar == single-valued), and the use of scalar() in the SQL layer. Single row results in the ORM are rows, not a single datatype. It's another potential point of confusion, like the ORM .select() is/was. I would say drop scalar() in the ORM namespace, and for single-row results, use .first() -- returns first row .one() -- returns first row, raise exception if more than one result On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote: one() raises an exception when theres not exactly one result, scalar () does not. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On Jun 4, 2007, at 9:56 AM, Rick Morrison wrote: The use of scalar() here seems out of place with both the common CS usage of the word (e.g. scalar == single-valued), and the use of scalar() in the SQL layer. Single row results in the ORM are rows, not a single datatype. It's another potential point of confusion, like the ORM .select() is/was. I would say drop scalar() in the ORM namespace, and for single-row results, use .first() -- returns first row .one() -- returns first row, raise exception if more than one result then we sort of have to rename list() to be all(). its all fine with me if everyone out there doesnt mind changing their code by the time 0.5 comes out --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
Well, I don't really see the connection between .scalar() and .list(), other than they are kind of antonyms, but FWIW I always thought that .list() was an odd duck anyway, seeing as how the arguably more Pythonic list(query) works fine. On 6/4/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jun 4, 2007, at 9:56 AM, Rick Morrison wrote: The use of scalar() here seems out of place with both the common CS usage of the word (e.g. scalar == single-valued), and the use of scalar() in the SQL layer. Single row results in the ORM are rows, not a single datatype. It's another potential point of confusion, like the ORM .select() is/was. I would say drop scalar() in the ORM namespace, and for single-row results, use .first() -- returns first row .one() -- returns first row, raise exception if more than one result then we sort of have to rename list() to be all(). its all fine with me if everyone out there doesnt mind changing their code by the time 0.5 comes out --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
Well, I don't really see the connection between .scalar() and .list(), other than they are kind of antonyms, but FWIW I always thought that .list() was an odd duck anyway, seeing as how the arguably more Pythonic list(query) works fine. (expanding on this a bit) More generally, it's the iterative nature of a query object that makes a lot of the .first() and so on more semantic sugar than anything else anyway. I'll routinely write things like: for row in query: process(row) or results = [process(r) for r in query] instead of: results = query.list() for row in results: process(row) I would even be OK with losing all the .select() and .first() and etc. completely and deal with queries using a library of function STL-like first-order functions like first(query) one(query) etc. so color me radical, I guess. Rick On 6/4/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jun 4, 2007, at 9:56 AM, Rick Morrison wrote: The use of scalar() here seems out of place with both the common CS usage of the word (e.g. scalar == single-valued), and the use of scalar() in the SQL layer. Single row results in the ORM are rows, not a single datatype. It's another potential point of confusion, like the ORM .select() is/was. I would say drop scalar() in the ORM namespace, and for single-row results, use .first() -- returns first row .one() -- returns first row, raise exception if more than one result then we sort of have to rename list() to be all(). its all fine with me if everyone out there doesnt mind changing their code by the time 0.5 comes out --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On Jun 4, 2007, at 10:47 AM, Rick Morrison wrote: Well, I don't really see the connection between .scalar() and .list (), other than they are kind of antonyms, but FWIW I always thought that .list() was an odd duck anyway, seeing as how the arguably more Pythonic list(query) works fine. I really like having a function on the end to give me all the results. having to go all the way back to the beginning of the line and put list() around the whole thing is not always convenient. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On Jun 4, 2007, at 3:27 AM, Neil Blakey-Milner wrote: The joined tables are aliased as the path from the base object. In this case, the jobtitle join is: INNER JOIN strids AS positionprofiles__jobtitle ON positionprofiles.jobtitleid = positionprofiles__jobtitle.id The domain__str__content join is: INNER JOIN dimensions AS positionprofiles__domain ON positionprofiles.domainid = positionprofiles__domain.id INNER JOIN strids AS positionprofiles__domain__str ON positionprofiles__domain.strid = positionprofiles__domain__str.id INNER JOIN content AS positionprofiles__domain__str__content ON positionprofiles__domain__str.id = positionprofiles__domain__str__content.strid ie, it joins on domain, then str, then content, giving each one an alias based on the path from the mapped object. those two joins are exclusive to each other (i.e. strids has a different alias in the second join than the first). this is the equivalent to what im proposing except i didnt have a deterministic (well, human-readable) naming convention in mind for tha alias names themselves. that naming scheme django is using cant really work anyway since it will very quickly go over the character limit of databases like oracle and firebird. I'm a little worried that using anonymous aliases will make some queries impossible. For example, if you want to list all purchases of product type B made by a manufacturer with a particular discount agreement, since one would require a filter_by(['product', 'store'], ...) and the other will require a filter_by(['product', 'type'], ...). In the Django ORM, since the path to 'product' is the same, it's the same join. i think you need to illustrate a clearer example since I dont understand the meaning of positionprofiles or strids above in relation to the names used in filter() (and what happened to Post?). from what I can see, the alias names are based on where the join is *going*, not where it came from so its not clear to me how this example would be accomplished. anyway, the filter on product/store and product/type example you just mention presents a third scenario, which I wouldnt consider to fall under the filter_by([attributes]) functionality, it would fall under the regular join() call which creates joins *without* aliasing. but, its not supported by the current attribute-joining functionality, because it asks to generate two joins from a common joinpoint that is *not* the root. the two ideas with regards to join() are the current way (join() moves the joinpoint which then never recedes) and the newer way (join() starts from the beginning each time). I just tried out an example of rejoining from the middle with the 0.4 code, with a mapping of User-Order-Keywords, Items create_session().query(User).join(['orders', 'items']).filter_by (id=5).join(['orders','keywords']).filter_by(id=7).list() and I got this: SELECT users.id AS users_id \nFROM users JOIN orders ON users.id = orders.user_id JOIN items ON orders.id = items.order_id JOIN orders ON users.id = orders.user_id JOIN keywords ON orders.id = keywords.order_id \nWHERE ((items.id = ?) AND (keywords.id = ?)) ORDER BY users.oid which is wrong, it joined on 'orders' twice (throws SQL error). but it seems like if join() were made a little smarter to see that 'orders' was already in there, which is pretty much required here since throwing an error is the least desireable option, youd get: SELECT users.id AS users_id \nFROM users JOIN orders ON users.id = orders.user_id JOIN items ON orders.id = items.order_id JOIN keywords ON orders.id = keywords.order_id \nWHERE ((items.id = ?) AND (keywords.id = ?)) ORDER BY users.oid where you can see the JOIN keywords is joining against the previous 'orders' table. I think that would work here and would be the approach for that scenario. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On Monday 04 June 2007 18:03:05 Rick Morrison wrote: Well, I don't really see the connection between .scalar() and .list(), other than they are kind of antonyms, but FWIW I always thought that .list() was an odd duck anyway, seeing as how the arguably more Pythonic list(query) works fine. (expanding on this a bit) More generally, it's the iterative nature of a query object that makes a lot of the .first() and so on more semantic sugar than anything else anyway. exactly. All() is much better than list(), in the means of list being just the current way/implementation of using ordered sequences. i guess it could return another container as well (like relation()). even if all these are gone: for row in query: process(row) break will give u .first() and for row in query: process(row) break else: raise someError will give u .one() svil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On 6/4/07, Michael Bayer [EMAIL PROTECTED] wrote: anyway, the filter on product/store and product/type example you just mention presents a third scenario, which I wouldnt consider to fall under the filter_by([attributes]) functionality, it would fall under the regular join() call which creates joins *without* aliasing. but, its not supported by the current attribute-joining functionality, because it asks to generate two joins from a common joinpoint that is *not* the root. the two ideas with regards to join() are the current way (join() moves the joinpoint which then never recedes) and the newer way (join() starts from the beginning each time). I just tried out an example of rejoining from the middle with the 0.4 code, with a mapping of User-Order-Keywords, Items create_session().query(User).join(['orders', 'items']).filter_by (id=5).join(['orders','keywords']).filter_by(id=7).list() and I got this: SELECT users.id AS users_id \nFROM users JOIN orders ON users.id = orders.user_id JOIN items ON orders.id = items.order_id JOIN orders ON users.id = orders.user_id JOIN keywords ON orders.id = keywords.order_id \nWHERE ((items.id = ?) AND (keywords.id = ?)) ORDER BY users.oid which is wrong, it joined on 'orders' twice (throws SQL error). but it seems like if join() were made a little smarter to see that 'orders' was already in there, which is pretty much required here since throwing an error is the least desireable option, youd get: SELECT users.id AS users_id \nFROM users JOIN orders ON users.id = orders.user_id JOIN items ON orders.id = items.order_id JOIN keywords ON orders.id = keywords.order_id \nWHERE ((items.id = ?) AND (keywords.id = ?)) ORDER BY users.oid where you can see the JOIN keywords is joining against the previous 'orders' table. I think that would work here and would be the approach for that scenario. Great! That's basically what I was trying to say. Sorry that I can't convey it in a more useful form. What do you think of me putting up the full pathological-case code from Django ORM and SQLAlchemy on the SQLAlchemy wiki, and maybe see if there are improvements to be found for that as well (since it uses ILIKE and not equality and a bunch of AND and OR statements, the new filter_by improvements can't be used for it). Just need to whittle it down to the bare minimum in terms of tables and code first. A bunch of real-life queries and the best code to achieve them would be invaluable on the wiki. Then, when changes to the API are discussed, the examples can serve as a baseline for the types of things that are being made easier or harder. Neil -- Neil Blakey-Milner http://nxsy.org/ [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On Jun 4, 2007, at 12:09 PM, Neil Blakey-Milner wrote:
What do you think of me putting up the full pathological-case code
from Django ORM and SQLAlchemy on the SQLAlchemy wiki, and maybe see
if there are improvements to be found for that as well (since it uses
ILIKE and not equality and a bunch of AND and OR statements, the new
filter_by improvements can't be used for it).
h...i dont like ILIKE (which isnt even present i every database)
by default. i think its best special operators just remain as
clauseelements, i.e.
filter(Class.c.attr.like('foo'))
on the subject of case sensitivity, there is an aging but ambitious
ticket to address it in a generic way, #487.
A bunch of real-life queries and the best code to achieve them would
be invaluable on the wiki. Then, when changes to the API are
discussed, the examples can serve as a baseline for the types of
things that are being made easier or harder.
yes that would be awesome. let me know what i can do to help.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On 6/4/07, Rick Morrison [EMAIL PROTECTED] wrote: The use of scalar() here seems out of place with both the common CS usage of the word (e.g. scalar == single-valued), and the use of scalar() in the SQL layer. Single row results in the ORM are rows, not a single datatype. It's another potential point of confusion, like the ORM .select() is/was. I would say drop scalar() in the ORM namespace, and for single-row results, use .first() -- returns first row .one() -- returns first row, raise exception if more than one result What if there are zero rows? Return None or raise an exception? I find the former useful enough, but I imagine some people prefer the latter. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
That's one of the reasons I prefer to treat Query() like an iterator and roll my own first-order functions like first() etc. -- see my other message regarding this. On 6/4/07, Mike Orr [EMAIL PROTECTED] wrote: On 6/4/07, Rick Morrison [EMAIL PROTECTED] wrote: The use of scalar() here seems out of place with both the common CS usage of the word (e.g. scalar == single-valued), and the use of scalar() in the SQL layer. Single row results in the ORM are rows, not a single datatype. It's another potential point of confusion, like the ORM .select() is/was. I would say drop scalar() in the ORM namespace, and for single-row results, use .first() -- returns first row .one() -- returns first row, raise exception if more than one result What if there are zero rows? Return None or raise an exception? I find the former useful enough, but I imagine some people prefer the latter. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On Jun 4, 3:11 pm, Mike Orr [EMAIL PROTECTED] wrote: .first() -- returns first row .one() -- returns first row, raise exception if more than one result What if there are zero rows? Return None or raise an exception? I find the former useful enough, but I imagine some people prefer the latter. one() raises an exception if not exactly one result. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
Well, that answers my next N anticipated questions on this list plus
essentially every unasked-yet one in my backlog. These consistency/
predictability-of-syntax/redundancy points cut to the core of every
issue I've had and/or every time I've had to hit the docs for more
than a brief reminder.
+1 oh yeah
On Jun 3, 8:35 am, Michael Bayer [EMAIL PROTECTED] wrote:
{super duper SQLA proclamation}
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote: - the methods select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by() and get_by() would be deprecated. this means they will remain present on the Query object but the documentation would be reorganized to talk only about filter(), filter_by(), list(), scalar(), and a new method called one() which is like scalar() but ensures that only one row was returned. I'm unsure about this but wouldn't one be redundant with scalar and [0]? Couldn't we have only one of either one or scalar (and have the check there) and otherwise let people use [0]. so..whattaya say ? Except from that little tweak, everything sounds great (you knew my opinion already but I couldn't resist saying it again)! -- 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote: - the methods select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by() and get_by() would be deprecated. this means they will remain present on the Query object but the documentation would be reorganized to talk only about filter(), filter_by(), list(), scalar(), and a new method called one() which is like scalar() but ensures that only one row was returned. +1 - by removing the word select from Query's API entirely, the timeless confusion of sql.select()? or query.select()? goes away. the identifier select at last loses its ambiguity. this is a big win. For this reason. SQLAlchemy has too many ways to do the same thing, and too many ways to access the same object. I would suggest renaming .list() to .all(). It seems funny having a method with the same name and same behavior as list(query) -- I can never decide which to use. There is the concern about building dozens of intermediate query objects that you immediately throw away, but that would be a good target for optimization. For instance, I'm not sure if it clones a query by rebuilding the criteria from scratch, or if it just copies one list of immutable (sharable) objects. If you can guarantee that the existing query won't be used anymore you can just reassign (share) the criteria as single unit, but I guess you can't guarantee that. - assignmapper would also keep all of its current methods with regards to selecting/filtering. it seems like tools like Elixir are going to move away from assignmapper anyway which is a good thing. It would still be worth a separate proposal to reform assignmapper; i.e., delete the query methods .foo() that duplicate MyClass.query().foo(). A lot of non-Exilir people use assignmapper, and it's frustrating that .select() exists but .filter() doesn't, so either add the missing methods or delete the redundant ones. On the other hand, this can be handled in the documentation by emphasizing .query() and deprecating the query methods. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On Jun 3, 2007, at 5:29 PM, Mike Orr wrote: I would suggest renaming .list() to .all(). It seems funny having a method with the same name and same behavior as list(query) -- I can never decide which to use. list() has been around awhile and is also derived from hibernate's similar interface, not sure if this is a good time to change that. There is the concern about building dozens of intermediate query objects that you immediately throw away, but that would be a good target for optimization. For instance, I'm not sure if it clones a query by rebuilding the criteria from scratch, or if it just copies one list of immutable (sharable) objects. If you can guarantee that the existing query won't be used anymore you can just reassign (share) the criteria as single unit, but I guess you can't guarantee that. im giong to look into optimizing the cloning. as ive said, hibernate's criteria object behaves generatively but doesnt actually copy the object; several folks here seem to want the generativeness. ive been considering sneaking in a flag/method that would turn off the generativeness but id have to make sure you dont notice it :). It would still be worth a separate proposal to reform assignmapper; i.e., delete the query methods .foo() that duplicate MyClass.query().foo(). A lot of non-Exilir people use assignmapper, and it's frustrating that .select() exists but .filter() doesn't, so either add the missing methods or delete the redundant ones. filter() and filter_by() were added in 0.3.8. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: whack query.select(), selectfirst(), selectone(), select_by(), selectfirst_by(), selectone_by(), get_by(), auto-join feature
On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote: im giong to look into optimizing the cloning. as ive said, hibernate's criteria object behaves generatively but doesnt actually copy the object; several folks here seem to want the generativeness. ive been considering sneaking in a flag/method that would turn off the generativeness but id have to make sure you dont notice it :). Does that mean returning the results immediately, or modifying the query in place and returning it? Maybe modifying the query in place and returning it isn't such a bad idea after all, considering that this is kind of a special case, having to call so many methods to build up a query. Most other OO systems don't require so many method calls to build up a meaningful object, but most other OO systems are not SQL queries either. And if it provides a way to get away from q = q.filter(...) in favor of q.filter(...), that would be an advantage. It gets tiring assigning the same variable to itself again and again when assignment isn't really the nature of what's going on. It would still be worth a separate proposal to reform assignmapper; i.e., delete the query methods .foo() that duplicate MyClass.query().foo(). A lot of non-Exilir people use assignmapper, and it's frustrating that .select() exists but .filter() doesn't, so either add the missing methods or delete the redundant ones. filter() and filter_by() were added in 0.3.8. Hooray. I've been following the trunk and reading the CHANGELOG but I didn't notice that feature. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
