[openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()
Matthew Booth
mbooth at redhat.com
Fri Nov 14 09:25:28 UTC 2014
On 13/11/14 18:26, Mike Bayer wrote:
>
>> 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.
Indeed, looks like there's just a single select here. Aggregate does,
however, fetch twice. This was the first one I found, and I may have
'seen' this pattern in more places than it actually exists.
Matt
--
Matthew Booth
Red Hat Engineering, Virtualisation Team
Phone: +442070094448 (UK)
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
More information about the OpenStack-dev
mailing list