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 preferable? 2. Existing Gherkin tests do not allow checking the property values, is it ok to add an integration tests or is it better to extend the test framework? On Mon, Oct 3, 2022 at 4:45 PM Valentyn Kahamlyk <[email protected]> wrote: > 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 side of the problem is fat vertexes with lots of properties, > making it necessary to have a way to limit the size of the transmitted data > and download only what is needed. > More details in Stephen's post > https://lists.apache.org/thread/xltcon4zxnwq4fyw2r2126syyrqm8spy. > Same issue with Edges and VertexProperties. > > Proposed solution > Implement new finalization strategy DetachStrategy(mode, vertexKeys, > edgeKeys, vertexPropertyKeys, fatVertexHandling) where mode is one of ALL, > REFERENCE or CUSTOM. > fatVertexHandling is an additional setting like "skip binary fields", > "skip arrays", "limit string length", "limit nesting". > vertexKeys, edgeKeys and vertexPropertyKeys are arrays of key names, data > types and options like type conversion handling (int -> float). Also these > fields can be replaced with a single `keys` parameter, this makes sense > when we end up with fields that do not belong to any Element. > > Pros: > - New strategy is mostly compatible with existing GLV's and server. > > Cons: > - Limited possibility to extend in the context of adding a schema. > > What do you think about this topic, does it make sense? > > Thank, Valentyn >
