Open Stack

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" <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
>>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
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev