Recently I tried started to use oslo.versionedobjects for a project. After playing around with it for a while, I noticed I could set "this is not a uuid" as the value of a UUIDField.
After making sure I made no mistakes - I looked at the underlying code, and found:[0] class UUID(FieldType): @staticmethod def coerce(obj, attr, value): # FIXME(danms): We should actually verify the UUIDness here return str(value) So, I went to implement this. [1] it quickly got -2'd as it would break Nova - so I went and implemented 2 steps of a 4 step process to get this field working as it should. In the review I was told: [2] "... I think that if a project wants that level of enforcement it needs to land the project, not in the library. Libraries ideally should support all supported branches of OpenStack." Basically - if a project wants the UUIDField to act like a UUIDField, and not a field that str()'s all input, they should copy and paste code around. This is being blocked by the -2 until Nova's unit tests are fixed (just Nova's - we have no way of knowing how many projects assumed it was testing UUIDness and will break) The steps I had looked at doing was this: 1. Allow a "validate" flag on the Field __init__() defaulting to False. 1.1. This would allow current projects to continue as is, and projects starting for the first time to do the right thing. 2. Deprecate the default value - issue a FutureWarning that it is changing to True 3. Deprecate the option entirely. 4. Remove the option, and always validate. 3 & 4 are even optional if some projects want to keep using UUIDFields like StringFields. Currently the -2 still stands as the reviewer does not like the idea of a flag. What are the options for this now? If we are supposed to support all stable branches of all projects, this is the only option if it is going to merge in the next 2 years. Or we can create a ActuallyValidatingUUIDField? Also, olso seem to be very -2 heavy. This means that alternative views on the review are very unlikely. My question is what is the difference between a -1 and a -2 for oslo? In designate we reserve -2 for things that will completely break our code, or is completely out of line for the project. (I would hope implementing a FIXME is not out of line for the project) Thanks, Graham 0 - https://git.openstack.org/cgit/openstack/oslo.versionedobjects/tree/oslo_versionedobjects/fields.py#n305 1 - https://review.openstack.org/#/c/250493/ 2 - https://review.openstack.org/#/c/250493/9/oslo_versionedobjects/fields.py __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev