Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Done!
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I proposed the listing on the dev list...the preview release is nice, but
could you reference it in your README so that it's clear. Also, please include
mention of "Apache TinkerPopâ¢" in
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Great work @danielcweber ! Thanks for your patience during the process.
---
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Alright, thanks!
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I'm not personally in touch with anyone over there really. I usually just
ping folks over there on twitter if I need to convey/ask something - try Luis
Bosquez:
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Thanks a lot for the twitter mention! In a completely unrelated issue, is
anybody of your team in contact with the graph implementors over at CosmosDB? I
have no luck in getting [this
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
nice @FlorianHockmann - i will manually close this PR now
@danielcweber hope we get to see some more pull requests from you in the
future. really nicely done - i bragged about your
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I guess it could qualify for the listing with some minor tweaks. It doesn't
have a release yet (things get deliberately broken by me all the time, so it's
at most in some version 0.x, if
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
neat - I'd be happy to suggest adding it to our provider index on the
tinkerpop home page assuming it meets the listing policy:
http://tinkerpop.apache.org/policy.html
please
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Thanks for accepting the contribution!
For what it's worth, I am developing a [type-safe
ORM](https://github.com/ExRam/ExRam.Gremlinq) (abusing the 'R' in ORM a bit ;-)
on top of
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I think I found the cause of the problem: We're using `dynamic` in
Gremlin.Net which requires the `Microsoft.CSharp` package. We always got that
package because Newtonsoft.Json also had a
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I don't know if this matters but I noticed that the upgrade of that JSON
thing didn't seem to matter to the tests. they passed on the old version (i
sorta tested that version by accident
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I'm looking into this. At a first glance it seems to be based on the
combination of the upgraded Newtonsoft.Json version and the addition of the
.NET Standard 2.0 target.
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I got the merge done on tp32, but when I merged to tp33 .NET wouldn't
build. I didn't immediately recognize the problem, so perhaps it's best that
@jorgebay or @FlorianHockmann pick it up
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I'm working on merging this now.
---
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/842
LGTM! VOTE: +1.
Thanks @danielcweber for the contribution!
Note to committers: I think it would be better to squash the commits ahead
of the merge.
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Great, thanks for making those changes.
My VOTE +1 from nearly 3 months ago still holds with these recent changes.
---
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Revised based on the comments, rebased onto the current tp32 branch.
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
@danielcweber the build is now failing because some of the added files miss
the required license header. Could you please add that?
---
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
@spmallette Should be symmetrical now!
---
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Sorry, I lost track of this issue since I worked around the TimeSpan issue
with simple longs (which can be summed up nicely which is impossible for
durations). I can delete the unneeded
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
@danielcweber should we expect any change here or is this ok to close at
this point?
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
> Symmetry doesn't help me much if my GLV decides to return some obscure
type that I can't process
I sense the chance of that is a bit low, especially if in the future we
look to
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
@spmallette I have been following the discussion. To be honest, I don't
care too much about the symmetry. Symmetry doesn't help me much if my GLV
decides to return some obscure type that I
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
@danielcweber thanks for your patience on this pull request. Sometimes the
seemingly simple tasks turn into larger more complex discussions unfortunately.
I'm not sure if you've
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
In case someone is following here but is not on the dev mailing list:
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
> @FlorianHockmann Why would we do that? If we can construct (i.e.
deserialize) e.g. a DateTime of whatever a server gives us, fine. Doesn't mean
we have to send (i.e. serialize) obscure
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I don't think it's wrong to mark something as "deprecated" in preparation
for a future non-usage that may or may not happen. I think the point is to
establish the intent to users that we no
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
>remove all deserializers again for which no serializer exists and vice
versa
Why would we do that? If we can construct (i.e. deserialize) e.g. a
DateTime of whatever a server gives
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
After thinking a bit more about this, my conclusion was that deprecating
those types doesn't really make sense unless we plan on GraphSON 4.0 as we
couldn't remove the types before that.
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
> Could we then somehow mark types as deprecated that we identify as
problematic for non-Java languages?
Not sure, but feel free to start fire up a DISCUSS thread on the mailing
list
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I'm ok with either direction - either to only support types symmetrically
or try to support at the reading site as much types as possible - as long as we
make that decision clear and
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/842
We probably should never have started support for those Java specific
duration types. dah - stupid exotic types. anyway...
There is no precedence for these extended types in GLVs
Github user danielcweber commented on the issue:
https://github.com/apache/tinkerpop/pull/842
I don't know how to get total symmetry into that. As long as Tinkerpop
I/O-docs don't explain the important difference between e.g. a Date and an
Instant, and as long as there are vastly
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/842
Sorry I'm late to the party, I haven't got much time during the past weeks:
nice contribution @danielcweber !
I'm a little concerned about the difference between serializers and
35 matches
Mail list logo
