> Seems to me like adding "native" support for other property upsert flows
that aren't overwrite will be very useful.
i think we've discussed this sort of thing before, but I don't recall if it
was on this thread or not, but I do think it would help simplify certain
code. You rexamples demonstrate
I'd like to expand on our use case. In our case, some property upsert
logic is rather complex - not just an overwrite. We're using the Python
language variant, so the examples are Pythonic.
For different properties, we need different property upsert logic. For
example, we have a property that
I gave a bit more thought to this one today. I think the stream case is
still stuck:
https://gist.github.com/spmallette/5cd448f38d5dae832c67d890b576df31#upsert-with-stream
Gremlin can only produce a Map which precludes T as a key. If
you look at the select()/project() signatures none of them nice
We may yet need to keep upsertV/E() as a new step because without that
addV() does get a bit odd as we would then lose the nice implicit match
behavior of:
// implicitly match on name/age without having to specify by()
g.upsertV('person', [name: 'marko', age: 29])
If we were to try to trigger tha
In general I like the idea of having a simpler way to express an upsert without
needing to know the coalesce pattern.
I am a little worried that if the addV and addE steps are overloaded to to
perform the upsert task that suddenly, steps that have always worked one way,
can now sometimes, do som
+1 to no new step. I haven't yet thought of a reason why this shouldn't
just be a variation on addV/E().
On Fri, Dec 11, 2020 at 1:03 PM David Bechberger
wrote:
> I agree with Josh's description of what the upsertV() functionality is
> intended to be.
>
> I also fully support the simplification
I agree with Josh's description of what the upsertV() functionality is
intended to be.
I also fully support the simplification provided by the by() modulation
that Stephen suggested, removing the second map. I think that provides a
much cleaner and easier to comprehend syntax.
With that agreemen
Josh, thanks for your thoughts - some responses inline:
On Tue, Dec 8, 2020 at 10:16 PM Josh Perryman
wrote:
> I'll offer some thoughts. I'm seeing upsertV() as an idempotent getOrCreate
> call which always returns a vertex with the label/property values specified
> within the step. It's sort of
I'll offer some thoughts. I'm seeing upsertV() as an idempotent getOrCreate
call which always returns a vertex with the label/property values specified
within the step. It's sort of a declarative pattern: "return this vertex to
me, find it if you can, create it if you must."
On that account, I do
ah - regarding 2, ok i couldn't remember and i didn't notice where we
talked about that when I scanned the thread. I've updated the gist
accordingly:
https://gist.github.com/spmallette/5cd448f38d5dae832c67d890b576df31
On Tue, Dec 8, 2020 at 10:51 AM David Bechberger
wrote:
> For #1 and 3 I
For #1 and 3 I agree. For #2 I thought that we agreed that the properties
within the upsert were going to be for creation only and that any
properties that needed to be updated would be done via the standard
property() syntax after the upsert. e.g.
g.upsertV('person', [name: 'marko'],
I started a expanded this discussion to gremlin-users for a wider audience
and the thread is starting to grow:
https://groups.google.com/g/gremlin-users/c/QBmiOUkA0iI/m/pj5Ukiq6AAAJ
I guess we'll need to summarize that discussion back here now
I did have some more thoughts to hang out there
Hello Stephen,
Thanks for making that gist, its much easier to follow along with the
proposed syntax there. To your specific comments:
#1 - My only worry with the term upsert is that it is not as widely a used
term for this sort of pattern as "Merge" (e.g. SQL, Cypher). However I
don't have a s
It's been a couple weeks since we moved this thread so I went back through
it and refreshed my mind with what's there. Dave, nice job putting all
those examples together. I've recollected them all together and have just
been reviewing them in a more formatted style with proper Groovy syntax
than wh
So, I've been doing some additional thinking about the ways that this could
work based on the comments below and have put my comments inline.
Dave
On Tue, Sep 22, 2020 at 6:05 AM Stephen Mallette
wrote:
> I added some thoughts inline below:
>
> On Fri, Sep 18, 2020 at 3:51 PM David Bechberger
I added some thoughts inline below:
On Fri, Sep 18, 2020 at 3:51 PM David Bechberger
wrote:
> Thanks for the detailed comments Stephen. I have addressed them inline
> below.
>
> I did read the proposal from earlier and I think that we are in close
> agreement with what we are trying to accompli
Thanks for the detailed comments Stephen. I have addressed them inline
below.
I did read the proposal from earlier and I think that we are in close
agreement with what we are trying to accomplish. I also fully support
Josh's comment on providing a mechanism for submitting a map of properties
as
I like our coalesce() pattern but it is verbose and over time it has gone
from a simple pattern to one with numerous variations for all manner of
different sorts of merge-like operations. As such, I do think we should
introduce something to cover this pattern.
I like that you used the word "merge"
I've had a few on and off discussions with a few people here, so I wanted
to send this out to everyone for feedback.
What are people's thoughts on creating a new set of steps that codify
common Gremlin best practices?
I think there are several common Gremlin patterns where users would benefit
fro
19 matches
Mail list logo
