I think there is a summit topic about what to do about a good 'oslo.db' (not sure if it got scheduled?)
I'd always recommend reconsidering just copying what nova/cinder and a few others have for there db structure. I don't think that has turned out so well in the long term (a 6000+ line file is not so good). As for a structure that might be better, in taskflow I followed more of how ceilometer does there db api. It might work for u. - https://github.com/openstack/ceilometer/tree/master/ceilometer/storage - https://github.com/stackforge/taskflow/tree/master/taskflow/persistence/bac kends I also have examples of alembic usage in taskflow, since I also didn't want to use sqlalchemy-migrate for the same reasons russell mentioned. - https://github.com/stackforge/taskflow/tree/master/taskflow/persistence/bac kends/sqlalchemy Feel free to bug me about questions. On 11/1/13 9:46 AM, "Clayton Coleman" <[email protected]> wrote: > > >----- Original Message ----- >> On 11/01/2013 11:14 AM, Clayton Coleman wrote: >> > ----- Original Message ----- >> >> Noorul Islam K M <[email protected]> writes: >> >> >> >>> Adrian Otto <[email protected]> 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#L4 >20 > >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 >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
