> 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 values, is it ok to add an integration tests or is it better to extend the test framework? Adding the capability to Gherkin seems unavoidable to some extent. This feature seems too central to future usage to escape Gherkin testing. On the other hand, adding that capability is a job in and of itself. It's just a suggestion but I'd be in favor of adding Java unit/integration tests initially to demonstrate that things are working. That body of work could be reviewed/merged. In the mean time, add a "Blocker" priority JIRA to come up with a plan to be able to test this capability with Gherkin and remove redundant Java tests that you added. Therefore the proposal for how the gherkin test syntax would look could be a separate issue. I guess we'd wait to add additional language variant support until that Gherkin work is done. On Tue, Oct 18, 2022 at 12:26 AM Valentyn Kahamlyk <[email protected]> wrote: > 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 > > >
