I just spent some time fixing:
https://issues.apache.org/jira/browse/TINKERPOP-2099
which dealt with inconsistencies in null handling for property() step when
there is a null value. That's all nice now, but null handling still isn't
so good overall. It's generally inconsistent in how it behaves in a variety
of uses in Gremlin - here's a couple examples:
gremlin> g.inject(null)
java.lang.NullPointerException
Type ':help' or ':h' for help.
Display stack trace? [yN]n
gremlin> g.V().constant(null)
gremlin>
I've also heard the concern on several occasions that mutation traversals
are often difficult to write when you want to remove a property and update
others at the same time, because it forces you into conditional logic where
you have to somehow work in a side effect of property("name").drop() as
opposed to just inlining property('name',null).
I think we should be a bit more respectful of the concept of null with
Gremlin and while we probably shouldn't allow a literal null into the
traversal stream, it seems like we could provide for our own Null class
that could be used in it's place where users/providers needed it, so that
we could do:
gremlin> g.inject(Null.instance())
==> null
gremlin> g.V(1).property("x", 1).property("y",
Null.instance()).property("z", 2))
==> v[1]
Perhaps we'd add a new Graph.Feature to allow providers to specify how they
handle such things. Taking this approach creates a position where we aren't
really changing core engine behavior. Instead, we're just adding a marker
that can be used by providers/Gremlin to identify the notion of null and
then updating serialization/GLVs to support it.
Haven't thought much past that point. Any other implications of taking this
direction?
