On Sun, May 24, 2015 at 11:28 PM, Lele Gaifax <l...@metapensiero.it> wrote: > Chris Angelico <ros...@gmail.com> writes: > >> You don't automatically get nice objects with attributes named after >> columns, but neither will SQLAlchemy unless you're doing the >> equivalent of "select * from". Example: >> >>>>> session.query(Student).all() >> [<__main__.Student object at 0x7fc2de3fc290>, <__main__.Student object >> at 0x7fc2de3fc350>, <__main__.Student object at 0x7fc2de3fc3d0>] >> >> That's a list of Student objects, because I asked for the entire table. >> >>>>> session.query(Student.name, Student.year).all() >> [(u'Fred', 2015), (u'Joe', 2015), (u"Robert'); DROP TABLE Students;--", >> 2012)] >> >> That's a list of tuples, because I asked for just two columns. > > Wrong: > > >>> res = session.query(Student.name, Student.year).all() > >>> type(res) > <class 'list'> > >>> type(res[0]) > <class 'sqlalchemy.util._collections.result'> > >>> type(res[0].name) > <class 'str'> > >>> type(res[0][0]) > <class 'str'> > >>> res[0].name == res[0][0] > True
Huh. Okay, was not aware of that. It's some sort of namedtuple-like thing that acts as a tuple but has attributes too. Very nice. I withdraw the criticism. My other criticisms were mainly on the basis that bad code is easier to write when you have more magic; rebuttals of the form "but nobody would be dumb enough to write code like that" are valid only to the extent that poor programmers are more likely to be using PHP than Python, so we're seeing a better calibre of coder here. But it's still very much possible to see - and have to maintain - some pretty horrendous code. Someone chooses to iterate over the query rather than calling .all() because "it's quicker that way" (it may or may not be, given that iterating over the query is lazy but all() is eager), and then calls session.commit() every hundred rows because "it's quicker that way". I've seen both of the above, although not together and not in SQLAlchemy. The latter is quite common; check out these advice pages, which seem to consider committing to be something you do for performance reasons rather than to enforce transactional integrity: http://www.ajaxline.com/32-tips-to-speed-up-your-mysql-queries http://stackoverflow.com/questions/14675147/why-does-transaction-commit-improve-performance-so-much-with-php-mysql-innodb -- question asked "Would you recommend COMMIT'ing every 1,000 or so INSERTS's..." That thinking is out there, and if you don't keep your transactions clear and clean, you WILL have problems. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
