[jira] [Updated] (TINKERPOP-3036) mergeV updating incorrect vertices and other issues
[
https://issues.apache.org/jira/browse/TINKERPOP-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-3036:
---
Priority: Critical (was: Major)
> mergeV updating incorrect vertices and other issues
> ---
>
> Key: TINKERPOP-3036
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3036
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Kelvin Lawrence
>Priority: Critical
>
> The following Stack Overflow post (link below) reported some issues with
> mergeV when side effects and cardinality are used (as well as with 3 mergeV
> steps chained together). The issue reproduces on 3.7.1 using TinkerGraph.
> [https://stackoverflow.com/questions/77803485/batch-mergev-working-well-when-creating-items-but-yielding-unexpected-results-w]
>
> Reproduction steps
>
> {code:java}
> gremlin> g=TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.mergeV([(T.id):'v-1']).
> ..1> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 12]).
> ..2> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> ..3> sideEffect(property(single, 'age',
> 22)).constant([:])).
> ..4> mergeV([(T.id):'v-2']).
> ..5> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 13]).
> ..6> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> ..7> sideEffect(property(single, 'age',
> 23)).constant([:])).
> ..8> mergeV([(T.id):'v-3']).
> ..9> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 14]).
> .10> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> .11> sideEffect(property(single, 'age',
> 24)).constant([:])).
> .12> id()
> ==>v-3
> gremlin> g.V().valueMap(true)
> ==>[id:v-2,label:Person,email:[perso...@example.org],age:[13]]
> ==>[id:v-1,label:Person,email:[perso...@example.org],age:[12]]
> ==>[id:v-3,label:Person,email:[perso...@example.org],age:[14]]
> gremlin> g.mergeV([(T.id):'v-1']).
> ..1> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 12]).
> ..2> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> ..3> sideEffect(property(single, 'age',
> 22)).constant([:])).
> ..4> mergeV([(T.id):'v-2']).
> ..5> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 13]).
> ..6> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> ..7> sideEffect(property(single, 'age',
> 23)).constant([:])).
> ..8> mergeV([(T.id):'v-3']).
> ..9> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 14]).
> .10> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> .11> sideEffect(property(single, 'age',
> 24)).constant([:])).
> .12> id()
> ==>v-3
> gremlin> g.V().valueMap(true)
> ==>[id:v-2,label:Person,email:[perso...@example.org],age:[24]]
> ==>[id:v-1,label:Person,email:[perso...@example.org],age:[23]]
> ==>[id:v-3,label:Person,email:[perso...@example.org],age:[14]]
> gremlin> {code}
> The query seems to be both updating values in the incorrect vertices as well
> as leaving some values unchanged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-3012) Wrong hashCode implementation for DetachedVertexPropert
[ https://issues.apache.org/jira/browse/TINKERPOP-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emanuele Tagliaferri resolved TINKERPOP-3012. - Resolution: Information Provided Hi, Thanks for the answer, I fixed it in the implementation using the right hashCode and equals helper, here is the commit: https://github.com/orientechnologies/orientdb-gremlin/commit/ccfa9197e1911c3d6261c2b5afc0d7ce87e8d6e0 > Wrong hashCode implementation for DetachedVertexPropert > --- > > Key: TINKERPOP-3012 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3012 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.7.0 >Reporter: Emanuele Tagliaferri >Priority: Major > Attachments: detached_vertex_property_hashcode.patch > > > Hi, > I was trying to update OrientDB to TinkerPop 3.7.0, and I got some test > failing, with some debugging I noticed that the `DetachedVertexProperty` > implement equals for the property, but inherit the hashCode from > `DetachedElement` that it does not behave as a property but as an element. It > may be there also other `VertextProperty` that do not implement correctly the > hashCode. > Adding a simple example patch in attachment. > here is the branch I'm working on for the update > https://github.com/orientechnologies/orientdb-gremlin/tree/WIP_update_deps I > do have additional tests failing to check -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-3012) Wrong hashCode implementation for DetachedVertexPropert
[ https://issues.apache.org/jira/browse/TINKERPOP-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cole Greer closed TINKERPOP-3012. - Assignee: Valentyn Kahamlyk > Wrong hashCode implementation for DetachedVertexPropert > --- > > Key: TINKERPOP-3012 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3012 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.7.0 >Reporter: Emanuele Tagliaferri >Assignee: Valentyn Kahamlyk >Priority: Major > Fix For: 3.7.2 > > Attachments: detached_vertex_property_hashcode.patch > > > Hi, > I was trying to update OrientDB to TinkerPop 3.7.0, and I got some test > failing, with some debugging I noticed that the `DetachedVertexProperty` > implement equals for the property, but inherit the hashCode from > `DetachedElement` that it does not behave as a property but as an element. It > may be there also other `VertextProperty` that do not implement correctly the > hashCode. > Adding a simple example patch in attachment. > here is the branch I'm working on for the update > https://github.com/orientechnologies/orientdb-gremlin/tree/WIP_update_deps I > do have additional tests failing to check -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-3012) Wrong hashCode implementation for DetachedVertexPropert
[ https://issues.apache.org/jira/browse/TINKERPOP-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cole Greer updated TINKERPOP-3012: -- Fix Version/s: 3.7.2 > Wrong hashCode implementation for DetachedVertexPropert > --- > > Key: TINKERPOP-3012 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3012 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.7.0 >Reporter: Emanuele Tagliaferri >Priority: Major > Fix For: 3.7.2 > > Attachments: detached_vertex_property_hashcode.patch > > > Hi, > I was trying to update OrientDB to TinkerPop 3.7.0, and I got some test > failing, with some debugging I noticed that the `DetachedVertexProperty` > implement equals for the property, but inherit the hashCode from > `DetachedElement` that it does not behave as a property but as an element. It > may be there also other `VertextProperty` that do not implement correctly the > hashCode. > Adding a simple example patch in attachment. > here is the branch I'm working on for the update > https://github.com/orientechnologies/orientdb-gremlin/tree/WIP_update_deps I > do have additional tests failing to check -- This message was sent by Atlassian Jira (v8.20.10#820010)
[Discuss] Type system in TinkerPop
Hi all, Now in embedded graph technically possible to use any JVM type, but for network transmission this set is more limited. Also there are some differences in GLV's, for example number handling in Python and Javascript. There are 2 main categories of Gremlin types: - some needed to transfer data over the wire, for example Graph Elements, lots of enums and other utility types like ByteCode and Bindings. - types designed to store data as values in a graph, like labels, property values, etc. This includes most simple types like numbers, strings, dates, and some composite types like collections (List, Set, Map). Some types like Integer used everywhere. Restricting values to a limited set of allowed types helps to decouple gremlin from its JVM foundation, and allows us to ensure that value types are handled consistently across all gremlin language variants. I would like to discuss whether it makes sense to put such restrictions on element property values? If yes, what types to allow to be used as element property values?
