There's some degree of history here as SQLAlchemy initially didn't have the whole "generative" notion of things, and the Mapper object itself would accept arguments which it passed mostly straight to a select() object. So you saw similar interfaces and it was kind of like switching between table.select(<all the arguments>) and mapper.select(<all the arguments>). There was a great emphasis on using regular select() constructs with mappers, and queries were always done in terms of Table objects, not classes - the idea of MyClass.foo=='bar' was introduced much later, even though this Table access was somewhat convenient via the ".c." attribute on classes (so MyClass.c.foo == 'bar' - this is actually completely different than what MyClass.foo is today). Overall there was a lot of SQLObject influencing how things were done.
If I were doing this again today, I might try to have a select() object that somehow morphs more smoothly into an ORM-centric object - though this would be challenging as the ORM Query does a lot of things with it's state before generating a much more rudimentary select() construct. The Query has a lot of opinions about things that the select() does not, even though our Query is still much closer to SQL than that of any other ORM. I have thought recently about this subject. But each time I try to consider there being just one construct that can move between them, the details of how that would work become apparently very hazy and unclear - it would take a lot of thinking. Still could be worth it, though. So as things turned out in 0.5, 0.6 and onwards, we've made the Query object be the "main" thing you work with when using the ORM. There's very little emphasis on using a select() construct directly except when embedding a subquery into an existing Query - but even then we have you build up the select() using the Query interface. The select() and Query still play together pretty well but we try to say when you're actually building select() constructs directly, you're working in a "schema-centric" fashion as opposed to a "domain-centric" fashion. If you're considering your query in terms of tables, and you want plain tuples back, that leans towards select([]), and if you're querying in terms of the object model, you use Query and can get back any combination of objects/tuples. I know it's not 100% "pure" but it does seem to work out pretty well. On Apr 12, 2012, at 2:06 PM, jo wrote: > Hi all, > > I'm sorry for this simple question. > What's the difference between query and select ? > are they interchangeable? > which of the two, it is best to use? > > -------> print(session.query(Azienda.c.data_inizio).limit(1)) > SELECT azienda_data_inizio > FROM (SELECT azienda.data_inizio AS azienda_data_inizio > FROM azienda) > WHERE ROWNUM <= :ROWNUM_1 > > > -------> print(select([Azienda.c.data_inizio]).limit(1)) > SELECT data_inizio > FROM (SELECT azienda.data_inizio AS data_inizio > FROM azienda) > WHERE ROWNUM <= :ROWNUM_1 > > > j > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" 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/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 [email protected]. 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.
