ORM on Steroids

Object Relational Mappers occupy an important role in today's database programming landscape. Most of them, sensibly, focus on generating SQL statements from various object activities and sending those statements to the database. There is nothing wrong with this approach, except that when you have a direct API to your Cluster Storage Engine like the NDBAPI, there is no point in doing all that work to generate SQL that MySQL is just going to turn right around and translate in to calls to the NDBAPI. It's an example of one of the times that the API is actually easier and more natural than SQL.

What would we do?

I've been working on a Proof of Concept ORM system designed to talk directly to MySQL Cluster over the NDBAPI using NDB/Python. I'm not wanting to sell people on Python (ok, so I am...) What I really want is a discussion of the benefits of using the NDBAPI in ORM systems in general. So we can use the POC ORM I've got as a basis of discussion. We can cover basic object creation and usage as well as internals of the ORM and possible strategies for moving forward. Hopefully, interest will be kindled in engineering some of the popular existing ORM Frameworks to allow for a direct NDBAPI layer. Perhaps we can eventually convince ActiveRecord, SQLAlchemy, Hibernate and the like to architect so that a direct NDB layer would be possible.

Who should we be?

The target audience here can also include anybody interested in the guts of an ORM, or people interested in seeing a functional example of NDBAPI programming that does more than just fetch a list of integers from a two column table.

Hacking on the ORM code is also welcome.

Interested in Participating? Put your name down

Monty Taylor