Description of RFE: It is not easy to compare whether the business entity i got by api.collection.get or api.collection.add equals to the one I updated/passed to add(). It would be good if there was some __eq__ method defined. It would be reasonable if, for example: True == (obj1 == obj2) iff they would be element-wise equivalent. True == (obj1 < obj2) iff obj1 had None where obj2 have defined elements, all other would be equal. Version-Release number of selected component (if applicable): ovirt-engine-sdk 95c1bbccf1c6ab93eeece287c6f5c7b3f334c656 Note that it is definitely possible to plug these methods to ovirtsdk.infrastructure.common.Base or ovirtsdk.xml.params.*, but it seems to me that more people could have gain from that if it was applied upstream.
The user of the SDK might want (we do want) to influence (not only) the __eq__ method, so It actually might be better to be able to register some other object factory method/class so people could have some control on objects creation without the need of a dirty monkey-patching. In other words, it would be great to be able to tell the SDK that it should create an instance of MyBetterHost (that is a descendant) of the ovirtsdk.infrastructure.brokers.Host Setting this to urgent because this would save us much of coding which we would soon have to do.
how this is related to sdk? the thing you describing is pure client side coding and completely not sdk prerogative, having common parameters holders used for DOC_TYPE programming and insuring that SDK signature always stays backward compatible, doing what you suggesting will break entire server/client DOC_TYPE oriented architecture. to save monkey-patching (as you called it) for yourself, write some inner implementation that will create context realated parameters holders. also objects not created via brokers, but from params, and each .create() method have __doc__ describing what parameters should be used and how.
(In reply to comment #2) > how this is related to sdk? the thing you describing is pure client side > coding and completely not sdk prerogative, having common parameters holders > used for DOC_TYPE programming and insuring that SDK signature always stays > backward compatible, doing what you suggesting will break entire server/client > DOC_TYPE oriented architecture. Say that there would be an AbstractFactory class for every broker and the client could subclass that and register it's factory object instead of some default for creating default objects. This customized object would be used to create customized instances of the brokers. I see no reason how that would break a "SDK signature". Of course the customised factory would have to respect some rules. Actually I think it would be safer than converting SDK objects to own objects and back for every action to be made. > to save monkey-patching (as you called it) for yourself, write some > inner implementation that will create context realated parameters > holders. As I understand (and I don't understand this statement much), you mean we should create our classes, that would be almost 1:1 to the SDK broker classes, except that they would have __eq__ and other stuff defined. > also objects not created via brokers, but from params, Well, not so true: In [13]: api.clusters.list()[0] Out[13]: <ovirtsdk.infrastructure.brokers.Cluster at 0x2cbae50> /usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py: class Cluster(params.Cluster, Base): > and each .create() method have __doc__ describing what parameters > should be used and how. There is no .create() method in `git grep create` in the sdk git repo.
On 02/07/2012 07:52 PM, bugzilla wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug. > > > https://bugzilla.redhat.com/show_bug.cgi?id=782891 > > --- Comment #3 from Jaroslav Henner <jhenner> 2012-02-07 12:52:03 EST --- > (In reply to comment #2) >> how this is related to sdk? the thing you describing is pure client side >> coding and completely not sdk prerogative, having common parameters holders >> used for DOC_TYPE programming and insuring that SDK signature always stays >> backward compatible, doing what you suggesting will break entire server/client >> DOC_TYPE oriented architecture. > > Say that there would be an AbstractFactory class for every broker and the > client could subclass that and register it's factory object instead of some > default for creating default objects. there are no 'default' objects, each resource creation using own parameters holder, having use-case specific parameter holder is against RESTfull application and DOC_TYPE programming principals. > This customized object would be used to > create customized instances of the brokers. you not suppose to create any instance of any object with broker, broker is only decorator in to entity, please review SDK documentation: http://www.ovirt.org/wiki/SDK#Creating_resource > I see no reason how that would > break a "SDK signature". Of course the customised factory would have to respect > some rules. Actually I think it would be safer than converting SDK objects to > own objects and back for every action to be made. i didn't say "SDK signature", but "DOC_TYPE oriented architecture", there are few core principals that our api build on and those principals valid for sdk as well, again functionality that you describing is client side implementation, or in other words - client implementations specific use-cases and this does not belong to sdk. > > >> to save monkey-patching (as you called it) for yourself, write some >> inner implementation that will create context realated parameters >> holders. > As I understand (and I don't understand this statement much), you mean we > should create our classes, that would be almost 1:1 to the SDK broker classes, > except that they would have __eq__ and other stuff defined. Jaroslav, we not talking about __eq__ method, but about "Coment 1" posted by you: "create an instance of MyBetterHost (that is a descendant) of the ovirtsdk.infrastructure.brokers.Host", => i don't mind adding __eq__, but NOT private implementations for "MyBetterHost" .... Further more, please do not mix different issues under same BZ > > >> also objects not created via brokers, but from params, > Well, not so true: as was mentioned above: this is only decorator for params.X > In [13]: api.clusters.list()[0] > Out[13]: <ovirtsdk.infrastructure.brokers.Cluster at 0x2cbae50> > > /usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py: > class Cluster(params.Cluster, Base): > > >> and each .create() method have __doc__ describing what parameters >> should be used and how. > There is no .create() method in `git grep create` in the sdk git repo. .create() implemented in sdk by collection.add(), - i suggest you start using some IDE, otherwise you missing core benefits of this sdk such as: self description, auto-completion, methods documentations etc. > -- Michael Pasternak RedHat, ENG-Virtualization R&D
in 3.1.0.2
closing ON_QA bugs as oVirt 3.1 was released: http://www.ovirt.org/get-ovirt/