
SQLAlchemy 0.9.0 Released - kbambz
http://www.sqlalchemy.org/blog/2013/12/30/sqlalchemy-0.9.0-released/
======
auvrw
a really solid, perhaps unique, library that, as far as i can tell, completely
addresses the "impedence mismatch" argument. if you're directly using a
database api in a structured way, you've probably already reimplemented the
sqlalchemy core, and refactoring your program to use sqlalchemy will give you
an orm, should you want one, and make your code portable across database
implementations even if you don't. if you're already using an orm, refactoring
to use sqlalchemy will allow you to to start optimizing the low-level database
operations in a coherent way (i.e. not just sprinkling SQL throughout the
models). there's a nice writeup in the architecture of open source
applications (
[http://www.aosabook.org/en/sqlalchemy.html](http://www.aosabook.org/en/sqlalchemy.html)
)

now, fantods aside, is there anything like this for java? according to the
aosa writeup, sqlalchemy's author found python's multiple inheritance useful
for implementing certain ideas, so porting probably isn't straightforward.
also, the relevant stackoverflow question (
[http://stackoverflow.com/questions/10537766/closest-
equivale...](http://stackoverflow.com/questions/10537766/closest-equivalent-
to-sqlalchemy-for-java-scala) ) seems inconclusive.

this is not to criticize java as a language, but rather because _i really wish
there was something like sqlalchemy for java_.

~~~
yareally
> _i really wish there was something like sqlalchemy for java._

Ebean[1], perhaps? I've only used it for a project in Play 2.0 that was built
on Java (it's built into Play 2.0), but it was far less painful compared to
other Java ORM libaries like Hibernate.

[1]
[http://www.avaje.org/ebean/getstarted_props.html](http://www.avaje.org/ebean/getstarted_props.html)

------
yeukhon
> support for Postgresql JSON types,

This. Finally :) I know I was searching this a few months ago and there was a
long due ticket for this to be added. Thank you whoever did this patch.

A side note. I personally use Pyramid (I use Pyramid more, however) and Flask.
For Flask project I never use flask-sqlalchemy because mitsuhiko doesn't seem
to update the repository as often as he should. A lot of outstanding tickets
and pull requests. Some are merged but they are never closed. So I always end
up bringing up SQLAlchemy myself into Flask because I just don't trust the
library. Is that how people feel too? For Pyramid, SQLAclemy is the "standard"
ORM to use and with ini file it is supposed easy to integrate SA into Pyramid
app.

~~~
bsaul
Currently on a big project using flask + sqlalchemy and didn't want to use
flask-sqlalchemy as well. At first, it was because it didn't seem like i
needed to, then it was for a better understanding of the sqlalchemy session /
flask request lifecycle coordination. That knowledge proved to be very useful
once i needed to reuse my stack in a celery task.

~~~
davidism
To solve this, I have a custom Celery instance that wraps each task in my
flask app's context. So you can treat celery tasks as just another request.

~~~
bsaul
Yeap, that's what i did as well, and i think that's the documented way ( using
a flask test request context i think). But having to do this let me understand
a lot more about sqlalchemy session, flushing and object states, in a
multithreaded environment. I recommend doing that for an in-depth
understanding.

------
TheSmoke
sqlalchemy is the best database toolkit for python developers. you can use it
as an orm or you can just use its core functionality; write sql expressions in
python, define your tables, columns and types. anything you can think of, in
terms of dbs, you can do with sqlalchemy.

i'd like to take a moment and thank to @zzeeek [1][2] and all of the
contributors.

[1]
[https://news.ycombinator.com/user?id=zzzeek](https://news.ycombinator.com/user?id=zzzeek)

[2] [https://twitter.com/zzzeek](https://twitter.com/zzzeek)

------
megaman821
Thanks for this release. Learning SQL before ever touching an ORM,
SQLAlchemy's approach makes a lot more sense to me than something "simplier"
like Django's ORM.

Anyone know, is there any chance Django would pull in SQLAlchemy core as a
dependency and implement their ORM on top of it?

~~~
scardine
The ORM is mediocre compared to SQLAlchemy, the template system is weak
compared to Jinja2.

If you swap Django's ORM with SQLAlchemy and replace Django Templates with
Jinja2, you end up with something like Flask.

The killer feature for me is Django's "admin" app. When I'm not using the
"admin", the rest of Django kind of gets in the way. Nowadays I prefer a less
opinionated framework like Flask if I'm not using the "admin".

Also, Django lacks any concept of multi-tenancy and does not support composite
primary keys nor schemas, which makes it a poor choice for SaaS projects. That
said, Django REST Framework is awesome for API-first development and makes it
a whole different game (in a positive way).

~~~
tga
In my experience the true killer feature of Django is the "batteries included"
approach. If you stay within the boundaries of the framework you get a
standard project structure, a decent ORM, a template language (dogmatically
crippled, but that's a different discussion), a forms handling library, and
the typical assorted framework toolkit (internationalization, logging,
development server, utilities, etc) -- all equally documented and maintained.
Compare this with having to choose and figure out individual libraries for
every one of the things above, each coming with different levels and styles of
documentation, communities, and resources.

The end result is that you spend less time deciding on small things and can
just use what's in the box. The real value is that the _next_ person working
on the code is already on the same page and can start working with it a lot
quicker.

~~~
thezilch
Nah, I'm not sure having all the libs bound together is the killer. I think
it's having all those libs with a cohesive set of docks and with a "single"
voice. I'm not sure that packaging Flask, Jinja2/Babel, WTForms, SQLAlchemy,
and Werkzeug (dev / debug server) together -- that should cover the non-admin
Django -- would improve the usage. Technically, Jinja2 and Werkzeug are
already dependencies of Flask, and their extensions page [0] are fairly
instructive on what other libs to pull in for the other needs. There's also no
reason one can't use Django, Jinja2/Babel, WTF, SQLA, and Werkzeug... we do!

[0] [http://flask.pocoo.org/extensions/](http://flask.pocoo.org/extensions/)

------
jgalt212
I dunno. I just don't get ORMs. I certainly see their use case in easy
prototyping, but with the advent of NoSQL, why not just prototype with
MongoDB, or similar, and if it turns out your data is close to uniform in
structure, just switch over to MySQL, or similar.

To keep my code portable, I stick to standard SQL and don't use any stored
procedures. I'm sure this is probably not a tenable strategy for web-scale
apps, but with 100s/1000s of users and only millions of records, it seems to
work just fine.

This comment is no way meant to disparage SQLAlchemy which by all accounts
seems to be a first rate work of engineering. I am speaking of ORMs in
general, and why should we use them.

~~~
meowface
Here are 3 primary advantages I can think of:

* Ability to programmatically add to/chain queries. It's really simple to add an additional "WHERE" clause in an ORM query; it's much harder to do so with a SQL string, where you have to account for escaping, comma placement, etc.

* Ability to automatically join entities in some cases, which can save on verbosity.

* Ability to add methods and attributes to models, which can abstract away additional queries or queries that might normally be really complex.

It's debatable if ORMs really add that much to productivity. I use them in
some projects, and forgo them in others. For Python, I'm a big fan of Pony ORM
because it can greatly reduce verbosity and basically maps Python code
directly to SQL; I don't really use it for the relational "mapping" though:
[http://ponyorm.com/](http://ponyorm.com/)

------
chrismorgan
Why is SQLAlchemy still under 1.0? Are there good reasons, or is it just the
apparently typical (and typically irrational) fear of the version number
"1.0"?

~~~
zzzeek
originally i was going to skip from 0.8 just to 1.0, but then a lot more new
features and behaviors came into 0.9, so i figured lets just do the one more
non-1.0 number. There's not going to be an "0.10", it'll be 1.0.

------
reinhardt1053
I'd love to have something as good as sqlalchemy in go

~~~
zzzeek
I looked at Go a little bit as maybe a place to write a kind of "uber-Core"
system, e.g. a high performance database abstraction layer that could power
libs in other languages. But apparently Go is not at all designed to be
embedded in other runtimes, it isn't even possible. Also it seems to lack a
standard database API and the connectors that were there seemed a little all
over the place.

~~~
dignan
Did you check out rust? That's within rust's feature set, though it isn't
"production ready" yet.

------
Demiurge
how does SQLAlchemy support for PostGIS compare to GeoDjango ORM?

~~~
mwhite
Looks like it's pretty robust:
[http://www.geoalchemy.org/tutorial.html](http://www.geoalchemy.org/tutorial.html)

~~~
psgibbs
It is, though if you're using PostGIS, I'd recommend GeoAlchemy2[1], which
ties into SQLAlchemy a bit more naturally (because they get rid of support for
all other engines). Also, seems to be more actively developed/maintained.

[1]
[https://geoalchemy-2.readthedocs.org/en/latest/](https://geoalchemy-2.readthedocs.org/en/latest/)

