Now that we have gremlin-io-test for 3.3.0 which tests different versions of gryo/graphson over different versions of tinkerpop (meaning the current version you build with ensure that it can still read/write the old formats) do we need to do this:
https://issues.apache.org/jira/browse/TINKERPOP-1364 I tend to think the answer is "no" at this point. I think that for the distributions we just need to have Gryo and GraphSON 3.0 and that's it (and obviously the existing GraphML files). If we do that we should get rid of a dozen files or so. Anyway, unless there are objections in the next 72 hours I will assume lazy consensus and move forward in that direction. On Mon, Jun 26, 2017 at 10:24 AM, Stephen Mallette <[email protected]> wrote: > Just wanted to note that Gryo 3.0 work is happening here in case anyone > wants to follow along: > > https://issues.apache.org/jira/browse/TINKERPOP-1698 > > I have a branch setup. I think I'm going to clean up Gremlin Server > configuration files for 3.3.0 and remove a bunch of the old serializers. > The config is starting to look really confusing. I think it would be best > to just have Gryo and GraphSON 3.0 configured in the packaged sample files. > > > On Tue, Jun 20, 2017 at 8:25 AM, Stephen Mallette <[email protected]> > wrote: > >> I'd really like to get our IO situation really solid in 3.3.0 and while >> we talk about GraphSON a lot I think Gryo still has an important place in >> our serialization story. Gryo covers an extended set of classes that goes >> beyond what we cover in GraphSON. I don't know if all those registered >> classes matter though - one would think that we just need parity with >> GraphSON defined classes. >> >> https://github.com/apache/tinkerpop/blob/9f13e69853c03a2fde7 >> 7efd40c6526b91a4b346a/gremlin-core/src/main/java/org/apache/ >> tinkerpop/gremlin/structure/io/gryo/GryoVersion.java#L192 >> >> I think that the reason this area of code has grown so much is from the >> basis of another issue with gryo which is that we don't always have a nice >> separation between implementations and serialized classes. In other words, >> if we have some complex class like DefaultTraversalMetrics, we just >> register all the classes that DefaultTraversalMetrics has as fields (and >> all the classes those classes use) until the serialization works. While >> this is really easy and, in a sense, convenient, it creates some problems: >> >> 1. We get this big long registration list which includes types we don't >> support in GraphSON (which typically aren't tested) >> 2. We have now bound the serialization of the complex class to its >> structure. If there is a problem with DefaultTraversalMetrics in the future >> and we have to change a field we essentially break all compatibility within >> gryo. (i'm facing this issue now actually). >> >> I would really like Gryo 3.0 to do a better job in this area, allowing >> for better forward and backward compatibility with a more limited class >> registration list that is more in line with the types defined for GraphSON >> support. I think we can get better forward/backward compatibility if (1) >> there is better separation between the object being serialized and the >> object used in application logic (think of the "detached" classes) and (2) >> gryo serializers for 3.0 have greater intelligence around internal >> compatibility handling. >> >> Anyway, I was mostly writing this as notes to myself in preparation for >> 3.3.0, but I'd be happy to hear any thoughts anyone might have on this. >> > >
