Comments for Taming Serpents and Pachyderms

Comment on Pyrseas contributions solicited by Joe Abbate: Pyrseas contributions solicited | The Black Velvet Room

Joe Abbate: Pyrseas contributions solicited | The Black Velvet Room — Fri, 17 May 2013 20:04:47 +0000

[…] via Planet Python http://pyrseas.wordpress.com/2013/05/17/pyrseas-contributions-solicited/ […]

Comment on A Pythonic, TTM-inspired interface to PostgreSQL – Requirements by Tuples in the Pythonic, TTM-inspired interface to PostgreSQL | Taming Serpents and Pachyderms

Tue, 26 Mar 2013 18:18:21 +0000

[...] Tuple of the TTM-inspired interface to PostgreSQL models TTM tuples as Python lists of TTM Attribute objects. Lists were used rather than sets [...]

Comment on Attributes in the Pythonic, TTM-inspired interface to PostgreSQL by Tuples in the Pythonic, TTM-inspired interface to PostgreSQL | Taming Serpents and Pachyderms

Tue, 26 Mar 2013 18:18:18 +0000

[...] ← Attributes in the Pythonic, TTM-inspired interface to PostgreSQL [...]

Comment on SQL Database Version Control – Summary by jma

jma — Sat, 23 Mar 2013 16:50:45 +0000

I’m afraid I can’t really tell what DataGrove is or does. I couldn’t find a simple description on its website, only that it “does all the behind-the-scenes magic” but without explanation of what the magic may entail. All the examples refer to MySQL so it seems their focus is on that rather than on PostgreSQL (the pachyderms in the title of this blog). DataGrove appears to be managing copies of (whole) MySQL databases which doesn’t quite compare to version control of database schemas, i.e., the meta-information describing the tables, columns, functions, etc.

Comment on SQL Database Version Control – Summary by Sroklis Daajekn

Sroklis Daajekn — Fri, 22 Mar 2013 21:24:19 +0000

Hi,
I am a bit late to this wonderful series of articles & a comparative analysis such as this. However it would also be interesting to hear from you what you think about http://off-scale.com/ DataGrove

Comment on A Pythonic, TTM-inspired interface to PostgreSQL – Requirements by Attributes in the Pythonic, TTM-inspired interface to PostgreSQL | Taming Serpents and Pachyderms

Thu, 21 Mar 2013 17:28:08 +0000

[...] ← A Pythonic, TTM-inspired interface to PostgreSQL – Requirements [...]

Comment on A Pythonic, TTM-inspired interface to PostgreSQL – Requirements by jma

jma — Mon, 11 Mar 2013 21:17:34 +0000

It does support nextval and default values: that’s what the sysdefault parameter of class Attribute is for. In any case, for my purposes I don’t need subqueries, group by, unions, etc. As I said in the post, this is not intended as an ORM-replacement. And if I needed more complex query features, I would never want to use an intermediary: it would be like learning German to speak through an interpreter to a Spanish person, when I can speak Spanish perfectly well.

Comment on A Pythonic, TTM-inspired interface to PostgreSQL – Requirements by Ants Aasma

Ants Aasma — Mon, 11 Mar 2013 20:24:43 +0000

The point is that you have built the equivalent functionality in Relvar.insert_one(). Except that you don’t support using function calls as values to be inserted (e.g. nextval(), uuid_generate_v4(), do_something_special(‘with value passed in’)), you don’t have insert_many, you don’t support INSERT DEFAULT VALUES. And while SQLAlchemy doesn’t have INSERT SELECT built in, implementing it is literally a dozen lines of code: http://stackoverflow.com/questions/1849375/how-do-i-insert-into-t1-select-from-t2-in-sqlalchemy

Now insert is just about the simplest example you can have. When you get to querying you may want to worry about sub-queries, group by and order by, possibly over arbitrary expression, unions and intersecting, distinct, selecting for update, custom operators, window functions, using server side cursor to incrementally process a result set and so on and so on. This is all out of the box available with SQLAlchemy. I don’t want to put down your effort, but I just don’t see what do you hope to achieve by essentially reimplementing SQLAlchemy besides the fun of doing it (a noble goal in itself).

Comment on A Pythonic, TTM-inspired interface to PostgreSQL – Requirements by jma

jma — Mon, 11 Mar 2013 18:45:37 +0000

But why would I bother with SA’s core? For example, what is the advantage of

users.insert().values(name=’jack’, fullname=’Jack Jones’)

over the comparable SQL INSERT command delivered directly to Psycopg2 and tailored exactly to my needs?

Comment on A Pythonic, TTM-inspired interface to PostgreSQL – Requirements by Ants Aasma

Ants Aasma — Mon, 11 Mar 2013 18:25:43 +0000

SQLAlchemy architecture does not require you to use it as an ORM. In particular, the ORM is cleanly layered on top of the SQL toolkit layer, allowing you to completely ignore all of the ORM features (or even mix and match if you like). In fact what you have built is in its concepts remarkably similar to SQLAlchemy core. (although obviously a lot simpler) Check the SQLAlchemy core documentation to get an overview of how the toolkit part looks like: http://docs.sqlalchemy.org/en/rel_0_8/core/tutorial.html
Or this is a great article detailing the reasoning and history behind the architecture: http://www.aosabook.org/en/sqlalchemy.html

I humbly disagree with your assessment of ORMs, as I have found SQLAlchemy’s variant to boost productivity, result in more readable notation, get out of the way when needed and be helpful of creating abstractions that actually result in better database design. But I have found that these discussions don’t tend to be too productive so I will leave it at a recommendation to just give it a try if you haven’t yet.