On 13/11/14 18:26, Mike Bayer wrote: > >> 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.
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 _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev