Open Stack

>
> >    - Possible performance issues, for example, some code that updates
> > a bunch of objects in a list, may not realize that each save() is
> > going across 2 amqp servers to reach the DB. This could be worked
> > around by adding a 'bulk update wrapper object' and using that (and
> > having it do the actual saving at the end). I'm in favor of something
> > like:
> >
> > with Transaction() as t do:
> >   for obj_id in ids:
> >      obj = Obj.get_by_id(obj_id, t)
> >      obj.foo = 'x'
> >      obj.save()
>
> Yep, this could be cool. I don't think we have any situations where we
> bulk-modify objects and write them back with a single call, at least
> none that come to mind. However, the thought I had for optimizing the
> get-all case could probably be used to optimize the write case,
> even above what we have today:
>
> If we have an object called Instance, we could also have an Instances
> object which is a collection of Instance objects. It would provide the
> get-all and get-all-by-foo methods. It could also provide a set-all
> method that would effectively call .save() on any of the items it
> contains that are dirty.
>
>
I really dig the idea and while it is not being used right now (multiple
set/save), I think that this will open up other possibilities and will be
used if it exists in the future.

This should definitely go into Oslo, this type of object / db abstraction
is a nice approach for moving towards more seamless upgrade paths, and I
don't see a reason the other projects wouldn't benefit from use of this
feature.

Cheers,
--Morgan Fainberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130506/dc056c03/attachment.html>