← Back to team overview

openstack team mailing list archive

Re: using objects returned from DB layer

 

On Dec 15, 2011, at 8:21 AM, Monsyne Dragon wrote:

> Actually, what we should be working to is using plain python model 
> objects, and having the sqlalchemy layer use it's mapper 
> functionality (separated from the models) to map db rows to those 
> models. THis will allow any persistence  layer to map to the same
> model objects, and allow us to have actual, object-oriented design 
> in our code. (like real methods, where appropriate)  This would
> suggest the dot notation, although making a python  model class
> support a dict interface for backwards compatability whilst things
> are refactored is easy to do. 

For what its worth, I've done extensive work with SQLAlchemy in the past
with a variety of products and services now in production, and am active
in the SQLAlchemy community (and friends with the creator/maintainer).

Monsyne's suggestion here is excellent. SQLAlchemy implements the
Data Mapper pattern for a reason. It gives you the ability to define
your domain objects in a nice, object-oriented fashion, with appropriate
state and behavior, and use attribute-based access for data, rather than
assuming a low-level datatype like a dictionary.

Then, you can utilize the SQLAlchemy ORM to map these domain objects to
a fairly arbitrary database schema for persistence purposes. This gives
you all of the power of the relational database under the hood, without
its rules and assumptions leaking into your object design.

SQLAlchemy, right on its front page of its website, says:

   SQLAlchemy is most famous for its object-relational mapper (ORM),
   an optional component that provides the data mapper pattern, 
   where classes can be mapped to the database in open ended, 
   multiple ways - allowing the object model and database schema to
   develop in a cleanly decoupled way from the beginning.

I'm fairly new to the project and community, but I wanted to pipe in and
share my experience with SQLAlchemy. If you actually use it as designed
and to its fullest, it really offers a very powerful and clean approach
to a difficult problem.

--
Jonathan LaCour
VP, Software Development
DreamHost
(W) 323.372.5984
(C) 404.784.1081


References