Context: I'm evaluating iTop and theorizing how to represent our processes in the iTop data model. I'm considering a generic scenario in which it would be desirable to mutate one subclass of change ticket into another without the need to recreate the object. The underlying motivation for wanting to mutate the class is to apply a different lifecycle to it without recreating the object. Assume I start with the non-ITIL change module, and create my own subclasses of a change ticket. The subclasses are similar but with differences in lifecycle.
If I were to define a class hierarchy in which all child classes are persisted in the same database table (with same or similar fields), can I then utilize an action (such as Set('finalclass','other_child_class_name')) to quickly mutate the object into another subclass? Would this be compatible with the ORM?
Is this a valid pattern to convert between similar classes with differing lifecycle rules? It may be the case that it is flat out impossible or prone to errors.
I'm weighing this theory vs the more established pattern of using an action to create a new object with attribute values copied from the original.
Thanks, Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Chris,
I do not recommend you to follow that path. iTop objects are not designed to be moved from one class to another class, the only situation where it might work, also I doubt that iTop offer any API to do it, is Jeffrey's proposal, where the various classes are child of a same parent, share the exact same list of fields including the status and its various values, and redefine the lifecycle (in which you can pick and choose the state values which are pertinent for your sub-class.)
@Jeffrey how to you transform a class into another ?
Is a set of 'finalclass' supported, really, or you did some hack in SQL ?
Last edit: Vincent @ Combodo 2022-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyhow, aside from that, all the new subclasses have exactly the same properties and even presentation (fields).
Originally I had a lot of network devices with a different "network device type", but that didn't provide for a nice "impact analysis". So to group each unique network device type, I changed this. I don't remember exactly if I either exported and re-imported everything, or (probably) used some MySQL queries to select a subset of networkdevice and generate the necessary IDs in the new tables.
For most other things, I could still rely on the fact that the new classes are subclasses (e.g. no need to adjust AttributeExternalKey pointing to NetworkDevice)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Context: I'm evaluating iTop and theorizing how to represent our processes in the iTop data model. I'm considering a generic scenario in which it would be desirable to mutate one subclass of change ticket into another without the need to recreate the object. The underlying motivation for wanting to mutate the class is to apply a different lifecycle to it without recreating the object. Assume I start with the non-ITIL change module, and create my own subclasses of a change ticket. The subclasses are similar but with differences in lifecycle.
If I were to define a class hierarchy in which all child classes are persisted in the same database table (with same or similar fields), can I then utilize an action (such as
Set('finalclass','other_child_class_name')) to quickly mutate the object into another subclass? Would this be compatible with the ORM?Is this a valid pattern to convert between similar classes with differing lifecycle rules? It may be the case that it is flat out impossible or prone to errors.
I'm weighing this theory vs the more established pattern of using an action to create a new object with attribute values copied from the original.
Thanks, Chris
I had a similar thing, but deliberately turned the classes into subclasses with their own database table (where typically just the ID is stored).
It inherits the presentation if no changes are made.
https://github.com/jbostoen/itop-jb-networkdevices
I think you can then add different life cycles
Hello,
Lots of things are possible with lifecycle...
Can you detail some functional use cases, so we can answer with possible solutions to implement ?
Hi Chris,
I do not recommend you to follow that path. iTop objects are not designed to be moved from one class to another class, the only situation where it might work, also I doubt that iTop offer any API to do it, is Jeffrey's proposal, where the various classes are child of a same parent, share the exact same list of fields including the status and its various values, and redefine the lifecycle (in which you can pick and choose the state values which are pertinent for your sub-class.)
@Jeffrey how to you transform a class into another ?
Is a set of 'finalclass' supported, really, or you did some hack in SQL ?
Last edit: Vincent @ Combodo 2022-07-04
@cisou you can see it here: https://github.com/jbostoen/itop-jb-networkdevices/blob/main/datamodel.jb-networkdevices.xml . I turned NetworkDevice in an abstract parent class. I actually notice now that I probably forgot to move "NetworkDevice" as an optional value for the "Model" class.
Anyhow, aside from that, all the new subclasses have exactly the same properties and even presentation (fields).
Originally I had a lot of network devices with a different "network device type", but that didn't provide for a nice "impact analysis". So to group each unique network device type, I changed this. I don't remember exactly if I either exported and re-imported everything, or (probably) used some MySQL queries to select a subset of networkdevice and generate the necessary IDs in the new tables.
For most other things, I could still rely on the fact that the new classes are subclasses (e.g. no need to adjust AttributeExternalKey pointing to NetworkDevice)