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
One of the concerns that came out of the DISCUSS thread for the pull request for TINKERPOP-1750 was that the gremlin-objects library might run into issues when dealing with a remote traversal, specifically one generated using the graph.traversal().withRemote(...) option. To quote Stephen Mallette, the issue is that "You get back a "reference" vertex which only has
the id and label - no properties."
Given that gremlin-objects terminates the GraphTraversal using either a next or a toBulkSet action, it may be possible that the properties in the resulting vertex does have the properties we need, in which case no changes would be required. If not, then we may need to explicitly ask for each property using the properties or values step, before doing the next or toBulkSet step.
In any case, a test case that addresses this use case is needed, and this issue tracks that effort.
The text was updated successfully, but these errors were encountered:
seems like this is inactive since long. Remote connection is important , currently it could be achieved by clustered client submitting queries. Existing solutions of embedded force to scale with client app.
These guys started but have a big issue for autogenerated id saving. Microsoft spring data gremlin
One of the concerns that came out of the DISCUSS thread for the pull request for TINKERPOP-1750 was that the
gremlin-objects
library might run into issues when dealing with aremote traversal
, specifically one generated using thegraph.traversal().withRemote(...)
option. To quote Stephen Mallette, the issue is that "You get back a "reference" vertex which only hasthe id and label - no properties."
Given that
gremlin-objects
terminates theGraphTraversal
using either anext
or atoBulkSet
action, it may be possible that the properties in the resulting vertex does have the properties we need, in which case no changes would be required. If not, then we may need to explicitly ask for each property using theproperties
orvalues
step, before doing thenext
ortoBulkSet
step.In any case, a test case that addresses this use case is needed, and this issue tracks that effort.
The text was updated successfully, but these errors were encountered: