Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <878uce2jh4.fsf@nautilus.nautilus>
References: <87fv6ol93p.fsf@nautilus.nautilus> <20150522224229.GA62222@cskk.homeip.net> <CAPTjJmpCuhqTwkxfCW48e8We=9Hp7UG3EeOiynH1nNy_LjnsZw@mail.gmail.com> <878uce2jh4.fsf@nautilus.nautilus>
Date: Mon, 25 May 2015 00:00:03 +1000
Subject: Re: Camelot a good tool for me
From: Chris Angelico <rosuav@gmail.com>
To: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.20.1432476007.5151.python-list@python.org>
Lines: 60
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:91183

On Sun, May 24, 2015 at 11:28 PM, Lele Gaifax <lele@metapensiero.it> wrote:
> Chris Angelico <rosuav@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