[openstack-dev] [Solum] Some initial code copying for db/migration
harlowja at yahoo-inc.com
Fri Nov 1 17:26:35 UTC 2013
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.
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.
Feel free to bug me about questions.
On 11/1/13 9:46 AM, "Clayton Coleman" <ccoleman at redhat.com> wrote:
>----- Original Message -----
>> On 11/01/2013 11:14 AM, Clayton Coleman wrote:
>> > ----- Original Message -----
>> >> Noorul Islam K M <noorul at noorul.com> writes:
>> >>> Adrian Otto <adrian.otto at rackspace.com> writes:
>> >>>> Team,
>> >>>> Our StackForge code repo is open, so you may begin submitting code
>> >>>> review. For those new to the process, I made a will page with
>> >>>> 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
>> > mechanical additions.
>> > I heard a few +1 for sqlalchemy with the standard OpenStack
>> > 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:
>? 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
>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
>> > I was also going to throw in migrate as a dependency and put in the
>> > code for that based on common use from ironic/trove/heat. That'll
>> > a few openstack common and config settings. Finally, was going to
>> > solum-dbsync command a la the aforementioned projects. No schema
>> > 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 at lists.openstack.org
More information about the OpenStack-dev