[
https://issues.apache.org/jira/browse/TINKERPOP-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731838#comment-17731838
]
Drew Nuttall-Smith edited comment on TINKERPOP-2952 at 6/13/23 3:22 AM:
------------------------------------------------------------------------
Hi Stephen,
Thanks for your response, I've only just gotten a chance to check this. Yeah I
do agree it is unusual to override these methods, and not something you'd want
to encourage. My specific use case is that we are using gremlin to model a
third-party graph model to allow users to run queries to check for
anti-patterns or other design issues. The model we are working with includes
nested properties and we wanted to be able to write declarative gremlin queries
to access the nested properties.
As an example. Image this "object" will be represented as a vertex:
{
{{ ...}}
{{ "parameters": {}}
{{ "id": 123,}}
{{ "name": "foo"}}
}
}
{{ ...}}
{{}}}
We want to be able to write queries like:
graph.V().properties("parameters).properties("name")
So we've implemented a java class called `ObjectValue` (for want of a better
name) which extends `TinkerElement` and implements the `property(String key,
Object value)` and `properties(String... propertyKeys)` methods.
The reason we want to override the `properties` method (and also `has` and
`values`) is to check the type before adding the `PropertiesStep` otherwise
we'll get exceptions when we hit primitive types. So we're not trying to modify
the behaviour of `properties` but just add some type safety so we can support
nested properties.
I hope that made some sense and also explained why we're trying to do this. Let
me know if there's any way we can achieve what we're trying to do here.
was (Author: JIRAUSER300284):
Hi Stephen,
Thanks for your response, I've only just gotten a chance to check this. Yeah I
do agree it is unusual to override these methods, and not something you'd want
to encourage. My specific use case is that we are using gremlin to model a
third-party graph model to allow users to run queries to check for
anti-patterns or other design issues. The model we are working with includes
nested properties and we wanted to be able to write declarative gremlin queries
to access the nested properties.
As an example. Image this "object" will be represented as a vertex:
{{{}}
{{ ...}}
{{ "parameters": {}}
{{ "id": 123,}}
{{ "name": "foo"}}
{{}}{{ }}}
{{ ...}}
{{}}}
We want to be able to write queries like:
graph.V().properties("parameters).properties("name")
So we've implemented a java class called `ObjectValue` (for want of a better
name) which extends `TinkerElement` and implements the `property(String key,
Object value)` and `properties(String... propertyKeys)` methods.
The reason we want to override the `properties` method (and also `has` and
`values`) is to check the type before adding the `PropertiesStep` otherwise
we'll get exceptions when we hit primitive types. So we're not trying to modify
the behaviour of `properties` but just add some type safety so we can support
nested properties.
I hope that made some sense and also explained why we're trying to do this. Let
me know if there's any way we can achieve what we're trying to do here.
> Error when overriding DSL methods
> ---------------------------------
>
> Key: TINKERPOP-2952
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2952
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.6.2
> Reporter: Drew Nuttall-Smith
> Priority: Major
> Attachments: dsl.patch
>
>
> I'm implementing a custom gremlin DSL in java, and due to some interesting
> requirements, I'm trying to override the `properties` method from the
> GraphTraversal class.
>
> Doing so results in a compilation error (see below) due to the method already
> being defined. It looks like the DSL code generation is loading in the custom
> methods, and then loading in the built in methods and the `@Override`
> annotation is ignored.
>
>
> Error:
> {{[ERROR]
> /Users/drewnuttall-smith/Documents/work/projects/compliance/dm-mettle-nextgen-compliance/target/generated-sources/annotations/com/datamigrators/mettle/compliance/gremlin/dsl/DatastageTraversal.java:[223,62]
> method <E2>properties(java.lang.String...) is already defined in interface
> com.datamigrators.mettle.compliance.gremlin.dsl.DatastageTraversal}}
> {{[ERROR]
> /Users/drewnuttall-smith/Documents/work/projects/compliance/dm-mettle-nextgen-compliance/target/generated-sources/annotations/com/datamigrators/mettle/compliance/gremlin/dsl/__.java:[192,85]
> name clash: <A,B>properties(java.lang.String...) and
> <E2,S>properties(java.lang.String...) have the same erasure}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
