New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python glv graphson update #448
Conversation
This looks good. However, can you please rebase with VOTE +1. |
20226ef
to
dcde4ed
Compare
Thanks Marko. |
To be honest, I think that we should move away from the |
I'm ambivalent on that. I just noticed unittest was present, and the bare assertions were not very informative. I can take that commit out if you think it's not worth it now. |
I like this. Much simpler, well tested, in general a nice PR. Pretty slick using the metaclass to create the de-/serializer maps. One thing I wonder: Presumably using the
That way the user can take advantage of the new functionality provided by the kwargs. Other than that and my previous comment. This is LGTM. VOTE + 1 |
I think that is a fine idea. I was mostly focused on the GraphSON API and not concerned with adding it to the token RemoteConnection implementation (figuring it would get pulled in if someone saw cause to do it). |
argh. needs a third rebase, too :-/ |
@aholmberg I know. Sorry. I'm not graceful. |
Yeah makes sense. I'm hoping to do some major refactors of the Driver over the next couple months anyway, but I'm juggling too many things right now. Either way this seems good to go. |
I like these changes. With a solid rebase of master/ given my recent VOTE +1. |
VOTE +1 |
Hi -- one thing to add. I notice you changed |
This was not Python-specific, but felt like a natural design to me. I unified the I/O per type, and tied those together at the top level in I can split them up, but then it means carrying around two things to encode/decode everywhere, instead of one:
I'll study the Java impl. a little closer to see if I can understand the benefit. Please let me know if you have any further thoughts. |
(also, ACK on rebase -- I should be getting to it today) |
dcde4ed
to
d296eb7
Compare
I haven't had a chance to get back to the GraphSONIO vs Reader/Writer question. |
Cool @aholmberg ... Here are some more pointers. Where Also, you might need to update https://github.com/apache/tinkerpop/blob/master/docs/preprocessor/awk/init-code-blocks.awk#L83 To test it -- |
Thanks. I see the code there. What is not clear to me is why these two things are divided, and why that API should be replicated here. I'm having a hard time doing this change because it makes it more cumbersome to use (at least for the integration I'm considering). I can vaguely imagine using readers and writers in a migration scenario where input and output are different. Can you help me understand the use case in the context of this GLV, where client IO uses a single format? |
@aholmberg We have had a distinction between reader/writer since the beginning of TinkerPop. I believe (@spmallette knows more) that there is a |
I don't think there's a use case in the context of the python GLV, but we have that use case in GraphSON in legacy support for TinkerPop 2.x based GraphSON (the migration scenario mentioned). I don't know that we'd extend that to Python. I guess the point here is to try to maintain API consistency across all the languages, even if we don't quite have all the support for all the features from Java applicable to Python just yet. |
Maybe we should clarify what APIs really need to be preserved. I have been thinking about the I'm working on splitting reader/writer now, but I'm not convinced this API is worth replicating here. We can chalk it up to my ignorance of the greater ecosystem machinery. |
not an ideal design by itself, but follows the Java API precedence, which has other requirements
imo i think that could be debated. at this point, i think being sorta cautious and following what's been working for a java though seems prudent. thanks for re-working. |
Pushed the split names. I didn't see issues related to these changes running |
A bit late to the conversation as I've noticed this hasn't been merged yet.
Considering that the GraphSONIO provides both a simpler API and easier integration as noted by @davebshow, plus it doesn't need to account for the legacy support, there are only benefits with this approach.
That's indeed a very good point. Assuming the main users of this API are the GLV implementors, then I'm wondering if making it idiomatic for the target platform shouldn't be the top goal. |
Hi @al3xandru .... This work has already been merged and will be released in TinkerPop 3.2.3. To answer your concerns though:
|
I have a series of gremlinpython graphson serdes simplifications, followed by a refactor to make type mappings an instance variable, rather than a module-level mapping. I did not attempt to preserve the module API since
gremlinpython
has not entered GA release status.I welcome any feedback.