[ 
https://issues.apache.org/jira/browse/TINKERPOP-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731838#comment-17731838
 ] 

Drew Nuttall-Smith commented on TINKERPOP-2952:
-----------------------------------------------

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)

Reply via email to