You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When dealing with subviews containing subqueries, it would be useful to be able to refer to the subview's context root. This fosters the independence of entity views from the view hierarchy they are used in as subquery providers can be implemented without knowing the view hierarchy. Consider the following example:
@EntityView(DocumentVersion.class)
publicinterfaceDocumentVersionView {
DocumentViewgetDocument();
}
@EntityView(Document.class)
publicinterfaceDocumentView {
@MappingSubquery(MyUselessSubqueryProvider.class)
publicList<UselessStuff> getMeUselessStuff();
publicstaticclassMyUselessSubqueryProviderimplementsSubqueryProvider {
createSubquery(SubqueryInitiatorinit) {
init.from(UselessStuff.class, "useless")
.where("useless.documentId").eqExpression("OUTER(document.id)"); // we have to know that we are nested in DocumentVersionView// .where("useless.documentId").eqExpression("VIEW_ROOT(id)"); -- VIEW_ROOT implicitely resolves to OUTER(document) context - the root of the DocumentView view.
}
}
}
The introduction of the VIEW_ROOT keyword for this purpose is a suggestion as it is quite intuitive in my opinion. Of course, we can decide for a different term as well.
The text was updated successfully, but these errors were encountered:
@Mobe91 Do you think we can dynamically add the additional functions to the parser?
I'd like to make the core independent of the entity view related functions.
I am imagining something like expressionFactory.createSimpleExpression("ABC(somePath)", Arrays.asList("ABC")) which would normally be illegal as ABC is not in the grammar.
This would allow us to properly parse the expression and then replace it with whatever we want.
When dealing with subviews containing subqueries, it would be useful to be able to refer to the subview's context root. This fosters the independence of entity views from the view hierarchy they are used in as subquery providers can be implemented without knowing the view hierarchy. Consider the following example:
The introduction of the VIEW_ROOT keyword for this purpose is a suggestion as it is quite intuitive in my opinion. Of course, we can decide for a different term as well.
The text was updated successfully, but these errors were encountered: