Database structure for archetype

[spine-o-bot]

In GitLab by @jkiviluo on Sep 19, 2018, 17:06

Over in https://gitlab.vtt.fi/spine/model/issues/62#note_3042 the discussion has covered more topics than what's in the actual issue. Here is one of them: how archetypes are represented in the database structure. Choices so far are:

Archetypes as objects

• would follow EAV-CR without changes
• use object_categories to distinguish from regular objects
• Toolbox code would be hard-coded to distinguish between archetype and regular objects
• need a table to link with parameters (for validation and valid ranges)

Each archetype would be it's own object class

• would allow hierarchical inheritance (unit --> CHP --> with SO2 emissions)
• Toolbox code would be hard-coded to distinguish between archetype and regular object_classes
• as object_classes they will get the treatment of object_classes in the Spine toolbox interfaces (but there needs to be 'if' clauses to establish separation in some cases, e.g. tick box in tree view to show either archetypes or regular object_classes)
• need a table for object_class related parameters (e.g. how many input commodities archetype can have)

Separate archetype table

• elevate archetype to EAV-CRA
• would allow hierarchical inheritance (between the archetypes)
• archetypes are not the same thing as object_classes, so this would be conceptually more clean (and code might be too)
• they won't be automatically treated as object_classes
  • functionality needs to be coded separately (but many things can be re-used after refactoring, e.g. adapted tree view)
• couple of new tables needed (Not hard to do. archetype, archetype__object_class, archetype__object, archetype__archetype_parameter)

The two last options would allow inheritance (maybe the first one too, I didn't think about it too much). So, that's really a separate question too.