MetaCase Homepage
Forum Home Forum Home > > MetaEdit+
  New Posts New Posts RSS Feed - Subtype after Creation of Object Type
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Subtype after Creation of Object Type

 Post Reply Post Reply
Author
Message
jfeuser View Drop Down
Contributor
Contributor


Joined: 29.Jul.2010
Location: Bremen, Germany
Points: 11
Post Options Post Options   Thanks (0) Thanks(0)   Quote jfeuser Quote  Post ReplyReply Direct Link To This Post Topic: Subtype after Creation of Object Type
    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?
Back to Top
jpt View Drop Down
MetaCase
MetaCase
Avatar

Joined: 25.Mar.2008
Points: 239
Post Options Post Options   Thanks (1) Thanks(1)   Quote jpt Quote  Post ReplyReply Direct Link To This Post Posted: 29.Jul.2010 at 16:52

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.
Back to Top
jfeuser View Drop Down
Contributor
Contributor


Joined: 29.Jul.2010
Location: Bremen, Germany
Points: 11
Post Options Post Options   Thanks (0) Thanks(0)   Quote jfeuser Quote  Post ReplyReply Direct Link To This Post Posted: 30.Jul.2010 at 13:13
Thank you, that was helpful.




Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 641
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 05.Oct.2016 at 10:20
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 XML

Most 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 supertype

In 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:

  • propertyRemovedFromSubtype.mxt, with the property slot cut from the subtype
  • propertyAddedToSupertype.mxt, with the property slot pasted to the desired position in the supertype’s list of slots

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.

  1. Select no projects and Login
  2. Switch to the Type Browser tab
  3. Repository | Import, and select propertyRemovedFromSubtype.mxt
  4. This will ask to open a project. Select the project that contains the metamodel, and hold Shift down as you press OK. If you are warned that types are also in another project, hold down Shift as you press OK. Keeping Shift held down avoids loading any models from those projects yet, protecting the existing instances from being updated and hence losing that property value.
  5. Repository | Import, and select propertyAddedToSupertype.mxt

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
Back to Top
jarno.leikas View Drop Down
Member
Member


Joined: 27.Apr.2021
Location: Jyväskylä
Points: 6
Post Options Post Options   Thanks (0) Thanks(0)   Quote jarno.leikas Quote  Post ReplyReply Direct Link To This Post Posted: 27.Apr.2021 at 06:31
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
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 641
Post Options Post Options   Thanks (1) Thanks(1)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 27.Apr.2021 at 10:39
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:
<object typeName="Child">
  <superType>
     <object typeName="OriginalParent">
</ </ </...
<object typeName="SupertypeToInsert">...</

then change it to:
<object typeName="Child">
  <superType>
     <object typeName="SupertypeToInsert">
        <superType>
           <object typeName="OriginalParent">
</ </ </ </ </...

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
Back to Top
jarno.leikas View Drop Down
Member
Member


Joined: 27.Apr.2021
Location: Jyväskylä
Points: 6
Post Options Post Options   Thanks (0) Thanks(0)   Quote jarno.leikas Quote  Post ReplyReply Direct Link To This Post Posted: 27.Apr.2021 at 10:40
Indeed, it's a combination of both. Thank you!
Back to Top
jpt View Drop Down
MetaCase
MetaCase
Avatar

Joined: 25.Mar.2008
Points: 239
Post Options Post Options   Thanks (0) Thanks(0)   Quote jpt Quote  Post ReplyReply Direct Link To This Post Posted: 24.Oct.2023 at 14:59
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
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.05
Copyright ©2001-2022 Web Wiz Ltd.

This page was generated in 0.063 seconds.