|
| Re: Create CheckConstraint [message #1821464 is a reply to message #1821457] |
Thu, 13 February 2020 12:40   |
 Zoltan Ujhelyi
Messages: 392
Registered: July 2015 |
Senior Member |
|
|
Hi Julian,
to be entirely honest, providing check expressions manually is really hard, the internal APIs are a bit hard to reuse. We usually either build the entire pattern from the textual syntax or work on a lower abstraction level, manually creating the PQuery structure where it is possible to add any Java code wrapped into IExpressionEvaluator instances. Neither solution is perfect - parsing the patterns is a bit more expensive, building PQuery instances manually results in validation rules are not executed (basically, you are expected to always provide well-formed query definitions using the API). Nonetheless, if either of these approaches work for you, I suggest going that way.
If not, I can only guess what is the error here. Most likely the problem with your case relies on some context not being set for the Xbase parser/interpreter - an expression like 'a < 0' would get to be translated to something like 'org.eclipse.xtext.xbase.lib.IntegerExtensions.operator_lessThan(a, 0)' - for that to work Xbase must know what is the type of the variable 'a'. To solve such issues with our Sirius-based graphical editor for graph patterns, we create a virtual pattern definition that has the minimum content necessary for the check/eval expression to compile and give that file to an embedded Xtext editor [1]. However, in this case we did not try to copy the XExpression to another resource or evaluate the created pattern so I am not sure whether such an approach would work for you.
Whichever direction you take, I have to warn you that we do not consider the EMF metamodel of the query language part of the API of VIATRA - in other words, it can change in future releases without warning. We make sure that the textual syntax remains compatible (a pattern written in the textual syntax will stay compatible with future VIATRA releases, but the same does not go for the internal EMF representation). Because of this reason, I'd like to ask your use case for building these EMF representations manually - I'd like to either understand what is missing from VIATRA or possibly suggest some alternative approach.
Best regards,
Zoltán
[1] https://git.eclipse.org/c/viatra/org.eclipse.viatra.git/tree/query/plugins/org.eclipse.viatra.query.patternlanguage.emf.sirius/src/org/eclipse/viatra/query/patternlanguage/emf/sirius/util/XtextEmbeddedEditor.java#n205
|
|
|
|
|
|
| Re: Create CheckConstraint [message #1822463 is a reply to message #1822311] |
Sat, 07 March 2020 15:21 |
Zoltan Ujhelyi
Messages: 392
Registered: July 2015 |
Senior Member |
|
|
Hi Julian,
I have some good news and some bad news about your original.
The good news is that I have figured out what is the issue and how to solve it: you have set up a classloader as context for the XtextResourceSet that can load the types/static methods required by the pattern definitions (using XtextResourceSet#setClasspathURIContext method, see https://javadoc.io/static/org.eclipse.xtext/org.eclipse.xtext/2.21.0/org/eclipse/xtext/resource/XtextResourceSet.html#setClasspathURIContext-java.lang.Object-), and after that point, the class gets resolved. This is not required in simple Java applications as usually there every class is available from the same classloader or when accessing methods from the Java Standard Library as those are always available from the default classpath.
The problem is that the Pattern Parser API does not expose the underlying Xtext Resource Set by design, so there is no easy way to set it up in the current release. For the upcoming 2.4 version, I have added a new method to PatternParserBuilder to specify a custom classloader that can be used. For an example of how this could work, have a look at the Gerrit change https://git.eclipse.org/r/#/c/158759/2/query/tests/org.eclipse.viatra.query.patternlanguage.emf.tests/src/org/eclipse/viatra/query/patternlanguage/emf/tests/standalone/PatternParserTest.xtend - If this would not work for you, feel free to add your thoughts.
Pre-release builds with this change should be available next week (after we review it internally), and it should be part of the first milestone build for version 2.4 coming later in March as well.
Best regards,
Zoltán
|
|
|
Powered by
FUDForum. Page generated in 0.03603 seconds
] 
Search
Help
Register
Login
Home
