How to add information about relations between entities to the index [message #1800123] |
Thu, 20 December 2018 04:37  |
Eclipse User |
|
|
|
Hi,
I designed a DSL that consists of Entities and Relations between them. Both Entities and Relations are top-level elements and each instance of them resides in their own file. Relations store the information to which entities they are connected, entities do not.
Example:
File1.dsl:
Entity MyEntityA {
...
}
File2.dsl:
Entity MyEntityB {
...
}
File3.dsl:
Relation MyRelationC {
from MyEntityA to MyEntityB
}
In order to build dependecy graphs between the Entities I have to traverse the Relations. However currently, I would have to traverse the complete index in order to find all Relations that are connected to a specific Entity (say MyEntityA). How can I make this more efficient?
What I tried:
- Adding userData to each Entity, containing the connected Relations. However, this information would need to be refreshed whenever a *Relation* changes, which does not seem to be possible.
- IReferenceDescriptions do not accept user data.
- Building an own secondary "index" for this pupose. It is able to invalidate any entries whenever a Listener fires (currently I am adding listeners to the IResourceDescroptions, i.e., the index) and provides O(1) access time for getting the relations that are active for a listener. However, it does not save its state to the disk (which makes in kinda useless, as whenever you start eclipse (without a complete rebuild) it is empty and provides the wrong information) and it does not manage dirty states properly.
- I considered changing the metamodel, so that each entity defines the Relations it is connected to. I do not like this approach though, as the information is redundant bloat. Of course, one could add QuickFixes and Validations to ease this approach, but I would prefer another solution, if possible.
So, before I rebuild the complete Xtext-Index: There is surely a better way to do it?
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.20301 seconds