Camelot a good tool for me

[Lele Gaifax]

Chris Angelico <rosuav at gmail.com> writes:

> On Sat, May 23, 2015 at 3:24 AM, Lele Gaifax <lele at metapensiero.it> wrote:
>> Laura Creighton <lac at openend.se> writes:
>>
>>> In my corner of the world, everybody uses SQL.
>>> [...]
>>> The people who have tried SQLAlchemy really didn't like it, and of course
>>> the people who haven't tried it do what their friends do, as usual.
>>
>> If these sentences are related, you must live in a very strange corner!
>>
>> ;-)

> Not sure why. I'm in the same corner, I think - I use SQL, and not
> SQLAlchemy if I can help it. I'd much rather just use psycopg2 and do
> my own queries.

Didn't mean to be so serious, but anyway...

> SQLAlchemy has its uses, and it does solve a number of
> issues in reasonably clean ways, but I don't like a few of its facets,
> including its peculiar way of doing foreign key relationships. (You
> put a foreign key in the child, and you put a relationship in the
> parent, which feels backwards.)

You are conflating two different layers, core and ORM. ORM relationships can
be declared either on the parent or on the child, it's up to your taste.

> There's a lot of magic going on.

Not in my experience, but I started using it long ago, so I'm biased.

> When magic works, it's great; but when anything goes wrong, it's harder to
> see what happened.

The same can be said of almost any upper layer in a software stack.

> Also, when does a transaction begin and end?

When I need transactions (that is, when I'm changing the database) I'm very
picky and use explicit begins, commits and rollbacks, so I don't recall
experiencing that doubt.

> If you session.commit() in the middle of iterating over a query, will it
> break the query? What if you roll back? Can you see, instantly, in your
> code?

Why would you do that? Are you closing your files while you iterate them,
without leaving the loop in some way at the same time?

> Even if the ORM layer is practically perfect in every way,
> there's still value in learning SQL; for instance, if you drop to a
> command-line interpreter like PostgreSQL's psql, or if you switch to
> another language, or anything like that, it's helpful to know what's
> going on under the covers. And if you have to know SQL anyway, the
> advantage of the abstraction layer has to justify the cost of learning
> an additional, not a replacement, API.

No doubt on that. Working with SQLAlchemy is not an alterative to knowing SQL
fairly well. SA does hide "details" (name quoting syntax, to mention one
obvious detail), but does not even try to hide the fact that it's talking SQL
all the way down.

I often have to deal with multiple DB engines at the same time, and being
able to "write" my queries with an abstract syntax is very valuable for me.

> So, while SQLAlchemy is definitely a lot better than most I've seen,
> it's still not really good enough for me to use everywhere. I'm mostly
> going to stick to the Python DB API 2.0.

Again, I fully agree: one should work with whatever tool he feels comfortable
with!

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.