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 for requests like "get all fields except binary"
On Thu, Oct 6, 2022 at 7:02 AM Divij Vaidya <[email protected]> wrote: > 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 wants specific set of > properties to be projected out (I.e. the CUSTOM configuration) could use > the existing operators to get the desired result instead of using g.V() in > a detached mode. We should also deprecate the detached mode at some stage > but that is a separate discussion. > > Hence, I don’t fully understand the need to add this additional > configuration. > > > On Mon, Oct 3, 2022 at 6: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 > > > -- > Divij Vaidya >
