OpenNebula XML-RPC python bindings, generateDS and pyone TemplatedType mixin class


As of version 2.39.2 generateDS has renamed generated methods that are non-public, which among others include buildChildren renamed to _buildChildren.

On the other hand, pyone's TemplatedType mixin class (src/oca/python/pyone/ overrides buildChildren method in order to perform custom building of hard-coded TEMPLATE and USER_TEMPLATE XML tags (as far as I understand, in order to coupe with xs:any type content available within mentioned tags).

Regardless of anyting, XML-RPC python bindings source code and make files will have to be adjusted to meet generateDS version 2.39.2 changes.

However, the way it is done right now, seems to me a little bit awkward – overriding non-public methods does not sound good practice. Moreover, currently the overridden method version is only applied to TEMPLATE and USER_TEMPLATE XML tags, however, xs:any type can also be found within other tags. For example, under VM_POOL/VM/MONITORING, or HOOK/HOOKLOG/HOOK_EXECUTION_RECORD, or CALL_INFO/EXTRA. This leads to situation when the same concept (xs:any) is processed differently depending on context (*TEMPLATE tag vs other tag).

Finally, looking at xsd files, it is obvious that often *TEMPLATE tags are not purely xs:any content, but rather mixture of some strictly specified tags and xs:any content. In this case again, the same concept (strictly defined tag) is processed differently depending on context (within *TEMPLATE tags it will be turned in to OrderedDict by overridden method, while within other tags it will be typed by some type generated by generateDS tool).

So, in order to unify processing of tags that contain xs:any content, I think OpenNebula XML-RPC python bindings should look into direction of overriding gds_build_any method of GeneratedsSuper class as per generateDS documentation.

Any thoughts / opinion on this subject matter?

Seems you are right in your findings. Thanks for the heads up!

I will start by fixing this. Then we can look into the overriding gds_build_any as you mentioned, but I wonder if we could somehow keep the backward compatibility. Because If the TEMPLATE shouldn’t be OrderedDict anymore I think we would break a lot of things.