> On Nov 13, 2014, at 3:52 AM, Nikola Đipanov <ndipa...@redhat.com> wrote:
> On 11/13/2014 02:45 AM, Dan Smith wrote:
>>> I’m not sure if I’m seeing the second SELECT here either but I’m less
>>> familiar with what I’m looking at.     compute_node_update() does the
>>> one SELECT as we said, then it doesn’t look like
>>> self._from_db_object() would emit any further SQL specific to that
>>> row.
>> I don't think you're missing anything. I don't see anything in that
>> object code, or the other db/sqlalchemy/api.py code that looks like a
>> second select. Perhaps he was referring to two *queries*, being the
>> initial select and the following update?
> FWIW - I think an example Matt was giving me yesterday was block devices
> where we have:
> @require_context
> def block_device_mapping_update(context, bdm_id, values, legacy=True):
>    _scrub_empty_str_values(values, ['volume_size'])
>    values = _from_legacy_values(values, legacy, allow_updates=True)
>    query =_block_device_mapping_get_query(context).filter_by(id=bdm_id)
>    query.update(values)
>    return query.first()
> which gets called from object save()

OK well there, that is still a single UPDATE statement and then a SELECT.   
It’s using an aggregate UPDATE so there is no load up front required.   Unless 
_from_legacy_values() does something, that’s still just UPDATE + SELECT, just 
not in the usual order.  I’d suggest this method be swapped around to load the 
object first, then use the traditional flush process to flush it, as regular 
flush is a lot more reliable, so I’d agree this method is awkward and should be 
fixed, but I’m not sure there’s a second SELECT there.

OpenStack-dev mailing list

Reply via email to