

Peewee, a lightweight python ORM - coleifer
http://charlesleifer.com/blog/peewee-a-lightweight-python-orm/

======
julian37
I haven't used Django ORM before but it would be interesting to see how Peewee
compares to SQLAlchemy: <http://www.sqlalchemy.org/>

I love SQLAlchemy: it is easy to use, rock solid, well documented, and fully-
featured without trying to do everything at once (for example, it explicitly
doesn't do caching).

The author and principal maintainer, Michael Bayer, does a fantastic job
developing the project at a sensible pace and answering any questions on the
mailing list quickly and patiently.

It is hands down one of the most well-run open source projects that I know of,
and a fantastic ORM.

Again, it would be interesting to see how Peewee stacks up against it
(performance-wise, since it obviously doesn't compete for features.)

~~~
zzzeek
A tiny one-file ORM (I checked, the full ORM itself is ultimately one file
"peewee.py") like Peewee that loads objects with a super-shallow stack depth
will have very low method call overhead for the things it does do, and in
Python method calls are everything. So an ORM like SQLA will appear slower on
simplistic benches which compare database sequences on a near one-to-one
basis. Where we try to be the most performant in the real world is that we try
to make it extremely easy to cut down the number of SQL calls in a complex
graph dramatically via collections, eager loading, stateful sessions, delayed
flush, etc.

~~~
coleifer
You couldn't be more correct.

------
j_baker
"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.

~~~
notaddicted
Fortunately there is a standard Python database API:
<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
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
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.

------
piotrSikora
Unless it contains auto-magical admin interface (like Django's ORM), why would
you ever use it over battle-tested SQLAlchemy?

~~~
j_baker
Some people will say that SQLAlchemy is complex, and there's a grain of truth
to that. But I personally think the maturity and featureset makes up for the
complexity.

~~~
stevenwei
I would also say that SQLAlchemy with the declarative extension is actually
incredibly easy to use.

And once you want to start doing the more complex stuff, SQLAlchemy handles it
all just fine, whereas other ORMs tend to fall short rather quickly.

~~~
j_baker
I agree, but easy to use != simple. For instance, I consider rails to be easy
to use, but not simple. :-)

------
qrush
Someone has Sequel/Arel envy :)

<https://github.com/rails/arel> <https://github.com/jeremyevans/sequel>

