[viatra-dev] Generated Query API update

[Zoltán Ujhelyi <zoltan.ujhelyi@xxxxxxxxxxxxxxxx>]

Hi all,

we have talked about modifying the code generator for VIATRA Query to reduce the number of files generated, and we have came up with two alternative strategies for this reason. Recently, this was implemented and should be available shortly in VIATRA builds (as of now the implementation is available in Gerrit changes [1-3]).

There are a two new configuration options available in the VIATRA Compiler preference page: (1) one disables the generation of pattern-specific match processors, while the other (2) selects one of three generation strategy for pattern specific matches and matchers.

--------------------
  Strategy   (i): 
--------------------
Generate match and matcher implementations as separate classes
Example:

src
-- pkg
   -- query.vql
src-gen
-- pkg 
    -- util
      -- Pattern1QuerySpecification.java
      -- Pattern2QuerySpecification.java
    -- Pattern1Match.java
    -- Pattern1Matcher.java
    -- Pattern2Match.java
    -- Pattern2Match.java
    -- Query.java (query group)

--------------------
  Strategy  (ii):
--------------------

Generate match and matcher implementations as nested classes of the query specification, and move the query specification out of the util package. The matcher API generated this way can be used similarly to the original implementation, so I could imagine using this as a proposed strategy for new projects.
Example:

src
-- pkg
   -- query.vql
src-gen
-- pkg 
    -- Pattern1.java (top-level: Query Specification; nested classes: Match, Matcher implementations)
    -- Pattern2.java (top-level: Query Specification; nested classes: Match, Matcher implementations)
    -- Query.java (query group)

--------------------
  Strategy (iii): 
--------------------

Do not generate match and matcher implementations, but rely on the generic ones; similar to private patterns since VIATRA 1.6. In this case, the query specification is also moved out from the util package. This strategy is useful for patterns only used in generic frameworks, e.g. patterns for derived features, surrogate queries or similar usage, as the generic API is hard to program for.
Example:

src
-- pkg
   -- query.vql
src-gen
-- pkg 
    -- Pattern1.java (top-level: Query Specification; GenericPatternMatch and GenericPatternMatcher classes referred, but not included)
    -- Pattern2.java (top-level: Query Specification; GenericPatternMatch and GenericPatternMatcher classes referred, but not included)
    -- Query.java (query group)


---------------------------

The pattern-specific match processors seems entirely unused in our experience, so turning it off seems to be possible without any migration cost; while the other change requires updating the code using pattern matchers. For backward compatibility, both options are set to provide exactly the same code as earlier.

I have noticed some performance effects of this change in two cases:

 * I have set up the generated code of our surrogate UML queries to use strategy (iii). This has resulted in a slightly better build time (as reported by Maven): the entire project originally took about 1:15 minutes to build before; after it finished in about 1:00
 * I have tried out the change together with the earlier import refactor in the same proprietary project. Executing a clean-and-build scenario for three projects with a few hundred patterns following strategy (i) took 3-4 minutes; while with strategy (ii) it took about 2 minutes. It is important to note that migrating the usage of the pattern matcher code was not done, and it seems to require quite a bit of effort.


I see three remaining tasks here (following the merge of the three changes):

  * Document the new options
  * Update the new project wizard to initialize new query projects with strategy (ii)
  * Given some classes are moved/renamed with strategy (ii), a new validator is necessary that identifies potential name clashes when that strategy is turned on.





If anybody has any concerns or ideas, feel free to share it, and I will do my best to address it.


Best regards,
Zoltán



 [1] https://git.eclipse.org/r/#/c/104188
 [2] https://git.eclipse.org/r/#/c/104284
 [3] https://git.eclipse.org/r/#/c/104189
-- Zoltán Ujhelyi

Eclipse Technologies Expert
IncQueryLabs Ltd.