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.
Of course I'm not saying this code is suitable for production. It's just a toy "ORM". How you could possibly think I'm trying to replace something like sqlalchemy with 50 lines of code? Please guys, I'm not gonna delete the repo. It's just for fun. I'll add a warning about the sql injection problems and explicitly tell that this code is NOT for production. Event when I think that is obvious.
I don't even think it's ready to be used in a prototype. No joins, no unions, as mentionned before SQL injections. I mean, besides teaching yourself what a basic Mapper is, I don't see any use to this.
Not just teaching myself. This could teach anyone else that didn't know about object mappers. Even if this is the most insecure code in the world, it can be improved. That's the reason it is on github. You could contribute and add joins, unions, sanitize the user inputs, etc.
Hey, it's a github repo. If you have discovered an issue with it, then clone the repo, fix the issue, and send in a pull request.
Yes, it does the simple form of variable substitution that opens the door to SQL injection attacks, but using a .execute method with ? in the SQL for variable substition is not the real solution. The real solution is what happens inside the .execute methods. There is no reason why that same code could not be incorporated in this mapper, and still maintain the goal of a minimal data access layer with no magic.
The advice given to programmers using an ORM or a database access library just doesn't work for programmers building one. He can't just "use" bind variables. He has to incorporate the concept into his code.
It is unfortunate that the Python DB-API evolved in the way that it did. It is only an API doc, and therefore every db library has to reimplement much of the same functionality, like the string escaping that prevents SQL injection attacks.
It would do a lot of good for a simple thin mapper like this to be more widely used so that more people can see what is involved in making things secure, as opposed to just piggybacking on a library that does everything for you.
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.
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.
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:
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).
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.
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.
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.