> have the server not stream the results and instead have the serializers handle the exact types returned from the GremlinExecutor.
I guess that would go back to the Rexster way of doing things. Wouldn't be hard to write a different kind of OpProcessor for this (i.e. one that is non-streaming for collections). One thing I don't like about it is that sometimes the user gets an Iterator then other times they get an Object and the choice is based on what their query is which a driver can't introspect. Making everything Iterator kinda solves that and reduces the choices the user has to make. On Tue, Oct 6, 2015 at 10:21 AM, Dylan Millikin <[email protected]> wrote: > Hey, > > I thought I would give my two cents here. I'd like to point out that I > mostly use the GraphSONSerializer without embedded types so there is no > distinction between both cases in that scenario. > > With that said I don't find the current implementation all that odd. It > might have been a little strange with Rexster but with the way > gremlin-server streams results I'd say that the behavior is expected. > People may even take advantage of it and stream large maps (I know I do). > > As far as allowing some other type of behavior I don't have much of an > opinion as to whether or not it should be implemented. My only inclination > would be to find this just a little too specific to warrant adding more > complexity to the configuration options. But how much of an issue that > really is I'm not sure of (I just think keeping things simple is often the > better course to take). Maybe Stephen can weigh in here. > > I will add that it could potentially make more sense if the question at > hand were to have the server not stream the results and instead have the > serializers handle the exact types returned from the GremlinExecutor. Not > sure if this is something that would/should be considered, just putting it > out there. > > Cheers. > > > > On Mon, Oct 5, 2015 at 3:28 PM, Bob B <[email protected]> wrote: > > > First, a quick heads up: in this post I am making a distinction between 2 > > similar terms: Iterator and Iterable. > > > > http://docs.oracle.com/javase/7/docs/api/java/util/Iterator.html <- e.g. > > Traversal > > http://docs.oracle.com/javase/7/docs/api/java/lang/Iterable.html <- e.g. > > Collection > > > > One of the things that I found surprising about Gremlin Server is that > when > > the response is an Iterable type then the items contained by that > Iterable > > are returned instead of the Iterable itself. This means that it is > > impossible to return a Collection from GremlinServer (without a hack). > > > > For example, if I execute the following via Gremlin Server > > > > 'map = [:]; map['foo'] = 'bar'; map['yee'] = 'haw'; map' > > > > ...then the response will contain 2 map entry pairs, not the map itself. > > The same goes for all Collection types. > > > > This is also a case where the behavior between Gremlin Server and the > > GremlinExecutor differs. Meaning, if the previous snippet is executed > > directly against GremlinExecutor then the result is a map, not the map's > > entries. > > > > Just to be clear, I have no issue with how *Iterator* types are handled, > > especially given the nature of how results are streamed from a Traversal. > > > > I'm fishing for feedback here because I know that Rexster and Gremlin > > Server have behaved this way for quite some time, and that's not a good > > sign for my viewpoint. Nevertheless, I'm wondering if it would be useful > to > > offer a configuration where Gremlin Server would iterate Iterator types > > only. > > > > Thanks, > > Bob > > >
