<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
>    - Possible performance issues, for example, some code that updates<br>
<div class="im">> a bunch of objects in a list, may not realize that each save() is<br>
> going across 2 amqp servers to reach the DB. This could be worked<br>
> around by adding a 'bulk update wrapper object' and using that (and<br>
> having it do the actual saving at the end). I'm in favor of something<br>
> like:<br>
><br>
> with Transaction() as t do:<br>
>   for obj_id in ids:<br>
>      obj = Obj.get_by_id(obj_id, t)<br>
>      obj.foo = 'x'<br>
>      obj.save()<br>
<br>
</div>Yep, this could be cool. I don't think we have any situations where we<br>
bulk-modify objects and write them back with a single call, at least<br>
none that come to mind. However, the thought I had for optimizing the<br>
get-all case could probably be used to optimize the write case,<br>
even above what we have today:<br>
<br>
If we have an object called Instance, we could also have an Instances<br>
object which is a collection of Instance objects. It would provide the<br>
get-all and get-all-by-foo methods. It could also provide a set-all<br>
method that would effectively call .save() on any of the items it<br>
contains that are dirty.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div style>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.</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>Cheers,</div><div style>--Morgan Fainberg</div></div><br></div></div>