Le 14/03/2015 01:13, Chris Friesen a écrit :
Hi,
I've recently submitted some code for review at
"https://review.openstack.org/163060";.
The change involves adding a new "reported_at" field to the Service
object class, and I'd like some feedback on the object-versioning
aspects of that:
1) Do I need to do anything special in obj_make_compatible()?
Yes, you need to make sure that you won't provide the new field to a
previous version of Service object.
See other examples on other objects to see how to do this.
2) Is what I've done in _from_db_object() correct? If I don't do it
like this, how is the "reported_at" field handled when a node sends a
v1.11 version of the object (or the corresponding dict) to another
node that wants a v1.12 version object?
_from_db_object is called for transforming a DB services table SQLA
object (ie. a tuple) into a NovaObject Service object.
By saying that you won't check it, it means that you won't have it
persisted on the DB table.
That's possible, but then you have to make sure you can either lazy-load
or have a Service property for the field so that you'll be able to value
the field.
About the compatibilty, that's quite simple : if an old v1.11 Service
object is sending its values to a v1.12 Service object, it won't have
the field set until someone is lazy-loading the new field or calling a
property.
3) Is it okay to lazy-load a "None" value in obj_load_attr()? The
nice thing about doing it this way is that a large number of
unit/functional tests can stay as-is.
No, that's not acceptable. The goal of obj_load_attr() is to lazy-load
fields by setting their values on the object. You should not return
anything but instead make sure that self.reported_at field is set.
Honestly, the patch is really big for being reviewed. I also have some
concerns about how you plan to fix the bug by adding a new field which
is not persisted, but I prefer to leave my comments on Gerrit, that's
what it's used for :-)
-Sylvain
Thanks,
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
