----- Original Message ----- > On 11/01/2013 11:14 AM, Clayton Coleman wrote: > > ----- Original Message ----- > >> Noorul Islam K M <noo...@noorul.com> writes: > >> > >>> Adrian Otto <adrian.o...@rackspace.com> writes: > >>> > >>>> Team, > >>>> > >>>> Our StackForge code repo is open, so you may begin submitting code for > >>>> review. For those new to the process, I made a will page with links to > >>>> the repo and information about how to contribute: > >>>> > >>>> https://wiki.openstack.org/wiki/Solum/Contributing > >>>> > >>> > >>> 1. .gitreview file is missing, so I submitted a patch > >>> > >>> https://review.openstack.org/#/c/54877 > >>> > > > > Once all the gitreview stuff is cleaned up I was going to do some purely > > mechanical additions. > > > > I heard a few +1 for sqlalchemy with the standard OpenStack abstraction: > > > > solum/db/api.py > > manager abstraction for db calls > > solum/db/sqlalchemy/api.py > > sqlalchemy implementation > > I wouldn't just copy this layout, personally. > > We should look at getting some of the nova object work into > oslo-incubator. It provides a nice object model to abstract away the > database API details. You really don't want to be returning sqlalchemy > models to the rest of the code base if you can get away with it. > > If we were starting the Nova database integration work from scractch > today, I'm not sure we'd have db.api and db.sqlalchemy.api. It seems > like it would make more sense to add the db.api equivalents to our > objects, and sub-class them to add specific database support.
Is what you're referring to different than what I see in master: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420 https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43 ? My assumption was that the db.api manager would be handling that translation, and we would define db.api as returning object models, vs sqlalchemy models (even if initially they looked similar). Would the abstraction for each model be split into different classes then (so that there would be one implementation per model, per backend)? What about cross model operations? If I describe the model used in other projects as: manager class translates retrieval requests into impl-specific objects saves impl-specific objects handles coarse multi object calls API #fetch_somethings(filter) #save_something would you say that your model is: abstract model class has methods that call out to an implementation (itself a subclass?) and returns subclasses of the abstract class Something #fetch(filter) #save SqlAlchemySomething #fetch(filter) #save ? > > > I was also going to throw in migrate as a dependency and put in the glue > > code for that based on common use from ironic/trove/heat. That'll pull in > > a few openstack common and config settings. Finally, was going to add a > > solum-dbsync command a la the aforementioned projects. No schema will be > > added. > > I also would not use migrate. sqlalchemy-migrate is a dead upstream and > we (OpenStack) have had to inherit it. For new projects, you should use > alembic. That's actively developed and maintained. Other OpenStack > projects are either already using it, or making plans to move to it. > Thanks, did not see it in the projects I was looking at, who's the "canonical" example here? _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
