3 ms·

"Only support for SQLite (at the moment)" This makes me skeptical. There's always some stupid, niggling little thing that each database does probably for no o

by j_baker 16y ago

"Only support for SQLite (at the moment)" This makes me skeptical. There's always some stupid, niggling little thing that each database does probably for no other reason than to be different for anyone else. ORMs can be challenging to write, and you never really get into one until you support 3 or 4 different databases. I'd be willing to bet that the code is a lot bigger than 1kloc by the time more databases get added.

irrelative 16y ago
You're completely right. This is the difference between releasing framework code, and releasing code that works for your application. Just because your internal code is extendable and clean doesn't make it worth using by other people. That just makes it good code. I'm not trying to rain on anyone's parade -- I think it's great that the author has released this, and he admits that it's scratching an itch for himself. This just shouldn't be considered a python ORM solution, but rather an python ORM for SQLite that works for the cases the author designed.
notaddicted 16y ago
Fortunately there is a standard Python database API: http://www.python.org/dev/peps/pep-0249/ http://www.python.org/dev/peps/pep-0249/ . Although it does take more effort to target the API than any single database adapter module.
- daeken 16y ago
  The API isn't all that matters, though. You have to deal with differences in types, differences in the way foreign keys are dealt with (e.g. in SQLite you can have a foreign key 0, but in Postgres you have to make it nullable and use null), differences in stored procedures. The API alone is minimal compared to the actual functional differences in RDBMS engines.
  - vilya 16y ago
    The API also allows a number of different syntaxes for query parameters: question marks, %-style format codes and one or two others as well and support for any particular style is optional. Last time I checked - a few years ago now - the styles supported by MySQLdb and psycopg were disjoint sets. Another wart: there is (or was) different named parameters to use when creating a database connection. One driver would use passwd, another would use password, for example. Those issues aside - and they only bite you if you're using several different databases - I really liked the simplicity of the DB API. Coming from the boilerplate hell that was Java's API it was a godsend.
artsrc 16y ago
ORM's seem to be problematic and complex. It seems to me to be valid pick one database, and to have an ORM which targets just that one database.

by j_baker 16y ago

irrelative 16y ago

You're completely right. This is the difference between releasing framework code, and releasing code that works for your application. Just because your internal code is extendable and clean doesn't make it worth using by other people. That just makes it good code. I'm not trying to rain on anyone's parade -- I think it's great that the author has released this, and he admits that it's scratching an itch for himself. This just shouldn't be considered a python ORM solution, but rather an python ORM for SQLite that works for the cases the author designed.

notaddicted 16y ago

Fortunately there is a standard Python database API: http://www.python.org/dev/peps/pep-0249/ http://www.python.org/dev/peps/pep-0249/ . Although it does take more effort to target the API than any single database adapter module.

daeken 16y ago
The API isn't all that matters, though. You have to deal with differences in types, differences in the way foreign keys are dealt with (e.g. in SQLite you can have a foreign key 0, but in Postgres you have to make it nullable and use null), differences in stored procedures. The API alone is minimal compared to the actual functional differences in RDBMS engines.
- vilya 16y ago
  The API also allows a number of different syntaxes for query parameters: question marks, %-style format codes and one or two others as well and support for any particular style is optional. Last time I checked - a few years ago now - the styles supported by MySQLdb and psycopg were disjoint sets. Another wart: there is (or was) different named parameters to use when creating a database connection. One driver would use passwd, another would use password, for example. Those issues aside - and they only bite you if you're using several different databases - I really liked the simplicity of the DB API. Coming from the boilerplate hell that was Java's API it was a godsend.

artsrc 16y ago

ORM's seem to be problematic and complex. It seems to me to be valid pick one database, and to have an ORM which targets just that one database.