Subtype after Creation of Object Type |
Post Reply |
Author | ||
jfeuser
Contributor Joined: 29.Jul.2010 Location: Bremen, Germany Points: 11 |
Post Options
Thanks(0)
Posted: 29.Jul.2010 at 13:47 |
|
Hi,
is there any possibility to make an existing object type (after its creation) a subtype of another one? Or is sub-typing only possible at creation-time? |
||
jpt
MetaCase Joined: 25.Mar.2008 Points: 239 |
Post Options
Thanks(1)
|
|
Hi, MetaEdit+ provides two ways for creating metamodels: form-based tools and graphical metamodeling. Form-based tools are the primary ones (see http://www.metacase.com/support/45/manuals/mwb/Mw-2.html#Heading233) emphasizing safety to guarantee that existing models open and work after the metamodel has changed. This comes with the limitation that you identified as form-based tools do not allow to change the supertype.
Graphical metamodeling (see http://www.metacase.com/support/45/manuals/Graphical%20Metamodeling.pdf) allows you to change the supertype (inheritance) but then you are in charge of considering the possible inconsistencies in your existing models. In your case consider for example that a binding constraint set for the supertype would then make some objects (of your current subtype) illegal. Should you delete those illegal ones, update them to another object type before the metamodel change or even change the constraints of the supertype first?
If you have not used graphical metamodeling you may then use plain XML to do the metamodeling work: which is actually a third way for metamodeling. Also graphical metamodeling stores the metamodels in XML before they are imported into MetaEdit+, but you can also export your current metamodel into XML and modify the XML directly and then import it again to MetaEdit+. See see http://www.metacase.com/support/45/manuals/mwb/Mw-7.html#Heading1981 for details.
However, if you don’t have models yet (like instances of your subtype), I personally would prefer creating a new subtype using the form-based tools and then simply reuse all the needed property types (add existing…), and copy the possible symbol definition and constraints given. This would be fastest way too since it takes less than a minute. You may then later hide or remove the unnecessary types or perhaps even use them later for some other purpose.
I hope this helps. |
||
jfeuser
Contributor Joined: 29.Jul.2010 Location: Bremen, Germany Points: 11 |
Post Options
Thanks(0)
|
|
Thank you, that was helpful.
|
||
stevek
MetaCase Joined: 11.Mar.2008 Points: 641 |
Post Options
Thanks(0)
|
|
There's an interesting special case if you already have important models, and want to push a property up or down in the hierarchy. At some point in that move, you would either have the same property slot twice in the hierarchy (illegal), or not at all (in which case all instances will lose that property and its value). Here are the details, and how to succesfully carry out this refactoring - from the draft manual of the next version (but applicable to 5.1 and older versions too):
8.5.3 Refactoring metamodels with XMLMost refactoring operations on the metamodels can be carried out simply with the existing metamodeling tools. For instance, renaming a type in the Object Tool is sufficient, with no need to manually update other parts of the metamodel that use that type (generators excepted). There are however sometimes specific operations or mass refactorings that would be easier or indeed only possible with XML. These can be accomplished by exporting the metamodel to an MXT file, modifying the file, and re-importing it. Moving a property slot to a supertypeIn the metamodeling tools, deleting a property slot from a subtype and adding it a similar one to the supertype will result in a new property slot, losing any existing values of that property in instances of the subtype. That is no problem when building the metamodel initially (no valuable instances will exist yet), but in the less common case of a major metamodel refactoring with existing models, it is good to have a solution that preserves all values. With careful MXT use, we can push the existing slot up into the supertype and maintain existing property values. Export the metamodel to an MXT file, and edit it to produce two new files:
The slot should include the <slot> tag and all its contents up to and including the closing of the slot tag. It is important that the internal slot id is the same as in the initial file. Normally the property type, typeName and local name should also be unchanged. Logout and take a backup of your repository, as before any major operation.
You can now look at the models back in the Graph Browser tab, opening and selecting projects as needed, and confirm that the property slot has maintained its values in existing instances of the subtype, and has new default values in instances of the supertype and its other possible subtypes. If all is well, you can commit. Edited by stevek - 05.Oct.2016 at 10:21 |
||
jarno.leikas
Member Joined: 27.Apr.2021 Location: Jyväskylä Points: 6 |
Post Options
Thanks(0)
|
|
Thanks for the explanation!
My refactoring needs require me to introduce new types "in the middle of" existing inheritance relationships (i.e. I need to introduce a new level of inheritance), after which I would then move my properties up or down. We also have existing models that we need to migrate to the new model. Is such a procedure possible somehow? Thanks! Jarno
|
||
stevek
MetaCase Joined: 11.Mar.2008 Points: 641 |
Post Options
Thanks(1)
|
|
Hi Jarno!
Sure, that should work. It sounds like what you want is jfeuser's "insert supertype" situation combined with my "promote/demote property slot" approach. I'd keep the two phases separate to make things simpler. The second phase is documented above; the first is rather easier, as you don't need to worry about existing instances - I'll document it below. Create the new SupertypeToInsert - in the same project as the other types, and preferably with no parent type. Add it to a graph type - you could create a temporary graph type with just these three object types. If you order them in the Graph Tool's Objects list as Child, SupertypeToInsert, OriginalParent, the XML will follow the structure below. Where you have:
then change it to:
Note that the <object> elements are in their full form the first time they occur, but if there are subsequent occurrences they will just be <object href="#xxx" />, where xxx is in the original element as an attribute id="xxx". You can add the id attribute where necessary, with its value the same as the typeName. When you're editing the files by hand, it's generally also ok to have the first occurrence of a type be with href="#xxx", and only later in the file have the full definition with id="xxx". Edited by stevek - 27.Apr.2021 at 10:39 |
||
jarno.leikas
Member Joined: 27.Apr.2021 Location: Jyväskylä Points: 6 |
Post Options
Thanks(0)
|
|
Indeed, it's a combination of both. Thank you!
|
||
jpt
MetaCase Joined: 25.Mar.2008 Points: 239 |
Post Options
Thanks(0)
|
|
Related to topics discussed in this thread, MetaEdit+ 5.6 provides refactoring tools covering changes in the type hierarchy. You can get this version now via Early Access.
Edited by jpt - 24.Oct.2023 at 14:59 |
||
Post Reply | |
Tweet |
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |