Open Stack

> On Nov 13, 2014, at 3:52 AM, Nikola Đipanov <ndipanov at 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.