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... ) seems inconclusive.
this is not to criticize java as a language, but rather because i really wish there was something like sqlalchemy for java.
Ebean, 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.
Full disclosure: Founder.
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.
i'd like to take a moment and thank to @zzeeek  and all of the contributors.
Anyone know, is there any chance Django would pull in SQLAlchemy core as a dependency and implement their ORM on top of it?
That said, I have on occasion floated an alternative idea, which is to basically port the Django configurational and query system to SQLAlchemy entirely, doing away with full backwards compatibility and essentially providing a "transitional" platform, where you take an existing Django application and basically run it on top of a new ORM layer that actually uses the SQLAlchemy Session and unit of work model, but the majority of the Django configuration and queryset behavior remains available, thus making porting a relatively painless process (but still, there'd be a porting process). This approach has two advantages. One is, it's actually doable, we're providing a new platform and not trying to duplicate an existing one. The other is, we're actually delivering to a Django application some of the biggest advantages SQLAlchemy has, which are namely the ORM features like unit of work/identity map, the instrumentation model including collections and eager loading support, and inheritance support.
Nobody has time / motivation for that idea either, but I think if it ever happened, it would be more pragmatic.
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).
I think it would have at least three positive outcomes:
* It would greatly increase support for the number of databases and database drivers.
* It would give developers something in between using the ORM or forgoing it and using SQL strings in raw() or db.connection().
* It would provide an easier path forward to adding additional capabilities into the Django ORM.
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.
I think the packaging and setup tools are getting better so maybe it doesn't always have to be that way.
You can also see the "no dependencies" claim on the Django website: https://www.djangoproject.com/download/, it's a selling point.
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.
* 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/
Really, it's a credit to just how much Mike got right on the first go.