There should be a guiding principle on this to make these decisions clearer. First would be: Gremlin should not concern itself with storage schemas. As an extension of that, Gremlin should not concern itself with storage size. Next would be: Gremlin should not be Java-specific. Finally, it should be hard to add a new type, i.e. it's demonstratively difficult to do a real world traversal without this type, how GLVs would map it, what functions on that type should be a part of Gremlin, and n>1 people positively affirm this direction.
Thus, there should be a minimal Core on which most else can be built. All extended types should be dropped. From Core, these should be dropped: Class (unless this is used for something important? Too many results on 'Class' in the codebase. Otherwise, it's just a string), Date (is a long), Timestamp (is a long, what's the diff to Date anyway?). There should be one floating point type which is 64-bit. There should be one integer type which is 64-bit. There should be a boolean (which seems to be completely missing??). Robert Dale On Fri, May 25, 2018 at 3:37 AM, Jorge Bay Gondra <[email protected]> wrote: > Thanks Florian for starting the discussion on this topic! > > I think its a good exercise to evaluate which types are necessary for a GLV > to support. > > I went through a similar exercise when designing the binary serialization > format. I'll go ahead and propose: > All types that are considered "Core", "Graph Structure" and "Graph Process" > in GraphSON3 <http://tinkerpop.apache.org/docs/current/dev/io/#_core_2> > plus the following from the "Extended" list: > - Short > - Byte > - ByteBuffer > - BigInteger > - BigDecimal > > The rationale is to select types that *can't be represented and stored* > using other types. > For example: > - Short can be stored using an int backing field, but it would take twice > the space. > - BigDecimal can be stored using a ByteBuffer but ordering on a buffer > doesn't align with decimal ordering. > > Regarding serialization and deserialization asymmetry on GLVs (for Core and > Extended types), I think we should avoid it as it could lead to obscure > error messages on the user side. > > I think we should provide a comprehensive type representation but it > doesn't have to be contain any type imaginable. The Gremlin Server and the > GLVs provide extension mechanisms that vendors and users can use to support > other types. > > 2018-05-24 14:31 GMT+02:00 Florian Hockmann <[email protected]>: > > > As part of the discussion for the pull request by Daniel C. Weber that > adds > > support for more extended GraphSON types to Gremlin.Net [1] we identified > > several of those types to be problematic for non-Java languages (or at > > least > > for .NET in this case) as they don't really have counterparts in other > > languages and for some it was even difficult to say where they differ > from > > each other. > > > > > > > > Now the question is basically what we want to do with those problematic > > types. > > > > > > > > My suggestion would be an approach like this: > > > > 1. Identify types that are problematic and that we therefore don't > > want > > to support across all GLVs. > > 2. Communicate to users somehow which types are problematic > (something > > like a deprecation) as we won't support them in all GLVs and maybe even > > stop > > supporting them at all at some point in the future. > > 3. Support the remaining types in all GLVs. > > > > > > > > Does that sound like a good plan? Are there any good ideas for the > > deprecation of those problematic types? My first idea would be to put > them > > in a different section in the I/O docs [2] that explains at the beginning > > that and why they are deprecated, but maybe someone here has a better > idea. > > > > > > > > Another question that was brought up during the review of the mentioned > PR > > by Jorge was whether types should only be supported symmetrically or > > whether > > GLVs should try to support types as good as they can. If someone has good > > arguments or a strong opinion for either side then it would of course > also > > be good to hear them. > > > > To give a concrete example of what is meant by symmetric support: > > > > In its current form the PR deserializes both GraphSON types gx:Duration > and > > gx:Period to the .NET type TimeSpan and it serializes TimeSpan back to > > gx:Duration. This means that gx:Duration is supported symmetrically, but > > gx:Period is not as there exists no .NET serializer that create a > > gx:Period. > > > > > > > > [1] https://github.com/apache/tinkerpop/pull/842 > > > > [2] http://tinkerpop.apache.org/docs/current/dev/io/#_extended_2 > > > > > > > > >
