[Sqlalchemy-tickets] Issue #3306: Splitting ORM and Core into seperate packages (zzzeek/sqlalchemy)

[nyov <iss...@bi...>]

New issue 3306: Splitting ORM and Core into seperate packages
https://bitbucket.org/zzzeek/sqlalchemy/issue/3306/splitting-orm-and-core-into-seperate

nyov:

Notice: This is a knee-jerk proposal, without much forthought about possibility of implementation.

I feel it would be nice, if at all possible, if SQLAlchemy could have a more obvious split into the abstraction layer / Core and ORM parts, at least providing two seperate packages and maybe a slightly different name for the core part even; having the ORM package depend on the core, obviously.

The reason is that I have found myself using SQLAlchemy Core with alternative strategies, most notably the Alchimi project for using the core abstraction layer with twisted and shunning the ORM, which is so problematic with these programming models.

I think projects like this could benefit from a dedicated Core package, and vice versa.
I'm not saying the code parts should deviate apart, not at all, both packages could build from the same source repository.

But more importantly, while the official documentation makes a distinct split between ORM and Core, people casually equate SQLAlchemy with ORM only throughout third party documentation:
When looking for solutions to problems, ideas, or code examples, *with the restriction of not using the ORM*, it's easy to get frustrated when opening up yet another blog post or code snippet going with an ORM solution.

That is of course inevitable when both parts share the same name and one is somewhat "hidden" in the guts of the other. There is just no good way to search the web for solutions with e.g. "SQLAlchemy prepared queries no ORM". All you'll get is "SQLAlchemy ORM" pages ;)

Because of this, some people will not even know that SQLAlchemy is useable as anything else than just an ORM, I know I didn't when first reading about it.
That might also explain why the great abstraction layer alone isn't so well known and represented on the web.

All of which is why I feel having a distinct *name* and *package* for the Core part (under the same SQLAlchemy umbrella) could be a good strategy for the project, if such a refactoring can be achieved.

Thanks for reading. Cheers