> 1. `Key` parameter of `DetachStrategy` can be
I'd vote for keeping it simple for now and just do option (a) which would
force folks to be explicit with the keys. The feature could be reconsidered
after users get a chance to try it.
> 2. Existing Gherkin tests do not allow checking the property
I started working on properties on elements and I will be grateful for
advice on 2 questions.
1. `Key` parameter of `DetachStrategy` can be
a) simple array of strings
b) same and support for wildcard like "data*" to get all properties started
with "data"
c) add regexp support
which option is more
Adding a strategy will allow more flexibility in controlling the result
with fat vertexes.
- we can use wildcards to select fields
- we can get all fields without listing them and keep the detached mode as
default behaviour
- we can have request-wide settings
- we can add type-related restrictions
Thank you for the proposal Valentyn.
If I understand correctly, you are proposing to add a configuration to
describe the expected projection from a query that returns a Vertex.
But this use case is already satisfied with project() and select()
operators that are provided by Gremlin. A user who wan
Hi all,
I would like to propose a solution for handling properties on Elements.
Problem
When a user writes `g.V()` they get back a Vertex object. The problem is
that depending on the execution context of the traversal, the result could
be quite different, with or without properties.
The other sid
