Absolutely, emphatically no.

Building SQL strings from user data is a terrible idea. You will have SQL injections. You will compromise your database. I'm sure someone else will add the obligatory link to the Johnny Droptables xkcd.

Just learn SQL. It is just not the hard. And please, please use bind variables.

This doesn't do joins, unions or anything remotely complicated that would allow me to "forget" about sql. SQL is a terribly important thing to know (especially if you work anywhere near a database), and can give more than just python code. Your micro orm is pretty nice, and Im not faulting your work which looks good, just saying add more work to it and its an ORM, and even then you shouldn't forget about sql. Unless this went over my head as a joke, then carry on.

I'm not expecting to get all the bells and whistles of an ORM in the 50 lines so my comment is on the code presented.

You probably want to escape the text.

Use the execute(QUERY[,optional parameters]) syntax.

http://stackoverflow.com/questions/902408/how-to-use-variabl...

The last query I wrote had 6 or 7 joins in it, a union, and calculated the frequency of answer responses for a worldwide survey (tens of thousands of respondents) in 0.04 seconds with a 1 million row table. You can accomplish an awful lot of business logic in a single SQL query, which makes SQL tremendously useful thing to know. On the other hand it is tedious to tweak an object mapper call to give you the result that you want that efficiently.

This is useful for abstracting away some routine SQL queries, but I think people think simple selects and inserts are more routine than they are actually are.. If you structure your data layer in a way that takes advantage of the power of the RDMBS I find that the only query here is truly routine is insertion on a single row...

We already have a language for expressing relational database queries - SQL. Every time you abstract away this language you risk reducing its expressiveness.

ORM's are for basic CRUD crap.

SQL is for queries that matter. My ORM usage is almost entirely limited to: get this record, change these values, save it. Anything involving complex joins/ unions gets thrown to raw SQL. Better yet, stored functions on the DB side. Postgres is awesome for this.

I agree with all the comments saying that this is dangerous and not a good idea in general. However I've been doing (and using) something related (more in the spirit of Clojure HoneySQL, as I discovered recently), where the idea is to ease the interop of plain data structures and SQL in a pythonic way:

https://github.com/cjauvin/little_pger

I always got the nagging feeling that I should rather use SQLAlchemy, which probably solves the problem in a more elegant and general way, but this little thing has been working great for me.

I have always wondered could something like this could be implemented as database backend for Django next to SQLite3, MySQL and Postgres backends. The reason for it would be ability to run tests that uses database w/o actually using database (because databases are freaking slow even when they are in memory).

Micro-ORMs were en vogue for a bit in .NET; I'm not sure about their status at present.

All SQL DSLs seem a bit over-the-top to me; you're layering a DSL atop another DSL (SQL), forcing you to understand the former intimately, along with knowing the latter well enough to write decent queries.

I fell under the spell of ORM, and used it until I had to generate an xml product feed from a large, complex CRM database. It didn't take me long to throw out Sequel and write a gigantic SQL query for huge performance gains. You can do joins in Sequel, but it's a pain in the neck.

For anyone looking for this actually done properly, there's already the SQLAlchemy query-builder layer.

It's most likely a troll.

On a side note, is SQL the only declarative language widely in use?