In response to Hristo’s post on: http://stackful.io/blog/discovering-sqlalchemy-core-the-relational-nosql-api-for-python/
I’m not sure but to me, SQLAlchemy Core seems to be a thin SQL generation / DBAPI translation layer. It wraps the relational model into a set of classes with OOish flavor to it. As you said, it is made up of building block classes for something more complex. I’m not just sure how to fit a NoSQL datastore behind the SQLAlchemy Core API; but I think with much effort it’s possible.
I do get that unexpressable want for an idiomatic, sexy API to the best object/data persistence solutions out there…
Good OO design promotes well-defined interfaces, separation of concerns, pluggability / testability, etc. Oh if only there’s a system where your class serializable definitions (as schemas, versioned copies (?)), object instances (lazily referenced), are all transparently instantiated/persisted to-fro the memory and non-volatile storage, plus there’s a rich API for adhoc queries. But wait, this sounds like a perfect OODB, or even an ORM, sadly there’s no one-size-fits-all solution.
Most OODBs will want you to walk the object graph to get your data.
ORMs try too much to be OOish but still require you to learn and master your RDBMS and SQL to be truly effective. Some even fall back to reinventing an SQL-like interface as a testament that adhoc query is difficult to tackle.
NoSQL stores are too specialized and their adhoc query facilities (if there are any), are so far behind with what the RDBMS world has to offer.
Think about the other attempts to this:
- Have a look at something like LINQ in the .NET world. Collections, maps, joins are first-class language features and transparently translated into SQL if applied to database-backed data.
- Checkout the experiments on functional DB APIs in clojure, scala, erlang.
- Django has that non-rel project but I haven’t really followed that effort and (as of this post, the last update was 8 months ago)
- Another example in Ruby there’s this DataMapper project, with an adapter to mongodb; for an ORM like api against SQL and nosql databases.
- Heck, Perl’s DBI have weird drivers to it (CSV, LDAP, mongo). Writing a driver means exposing something as a tuple store.
- Java has JPA as a standard, and there are implementations that support NoSQL data stores; e.g. I think EclipseLink supports MongoDB, Oracle NoSQL among others.
On final thought, pro-RDBMS people promote the idea that data is the first class citizen, the application code secondary; And I agree with what they’re saying that your data will surely outlive your application. Tuples, joins, normalization / zero-redundancy goes back to relational theory / algebra which to me makes good sense. So we continue to ask and mind the thought: what is this “object-relational impedance mismatch” really about and if it’s that real, are we close to a good-enough solution?
Interesting Reads and Discussions:
Orm Haters Do Get It – HN discussion
OrmHate – HN discussion
Orm Is an Anti-Pattern – HN discussion
On one of my free days, I was on a lookout for a free subversion hosting, for a private project. There are several free SVN hosting for opensource projects (
It’s been 5 days since my shiny pre-owned notebook arrived. Considering it’s size, specs and above all, price, this sure is a bargain find from 
akosidexter 
You must be logged in to post a comment.