AtomicTitanQuery throws IllegalArgumentException if property key does not yet exist

[DanielThomas]

This behaviour is inconsistent with Blueprints DefaultQuery. In this case we want the edges that do not have a property set:

.has("end", null)

This works fine with OrientDB and Neo4J with Blueprints, however Titan's native implementation throws:

java.lang.IllegalArgumentException: Unknown property key: end

[DanielThomas]

I should say though, it's gratifying to see that Titan is so strict about state and not allowing nulls. Attempting to set a property explicitly to null results in:

java.lang.NullPointerException
    at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191)
    at     com.thinkaurelius.titan.graphdb.relations.factory.StandardPersistedRelationFactory.createNewProperty(StandardPersistedRelationFactory.java:58)
    at com.thinkaurelius.titan.graphdb.transaction.AbstractTitanTx.addProperty(AbstractTitanTx.java:194)
    at com.thinkaurelius.titan.graphdb.relations.LabeledTitanEdge.addProperty(LabeledTitanEdge.java:251)
    at com.thinkaurelius.titan.graphdb.blueprints.BlueprintsVertexUtil.setProperty(BlueprintsVertexUtil.java:33)
    at com.thinkaurelius.titan.graphdb.relations.LabeledTitanEdge.setProperty(LabeledTitanEdge.java:262)

If I add a valid property to at least one edge, has("end", null) will then fail with:

Exception in thread "main" java.lang.IllegalArgumentException: Value is not an instance of the property key's data type.
    at com.google.common.base.Preconditions.checkArgument(Preconditions.java:92)
    at com.thinkaurelius.titan.graphdb.query.AtomicTitanQuery.has(AtomicTitanQuery.java:149)
    at com.thinkaurelius.titan.graphdb.query.AtomicTitanQuery.has(AtomicTitanQuery.java:158)
    at com.thinkaurelius.titan.graphdb.query.AtomicTitanQuery.has(AtomicTitanQuery.java:1)

This discussion seems to indicate that has("property", null) is intended to be used for this purpose:

https://groups.google.com/d/topic/gremlin-users/1POt0kzru7g/discussion

So handling for both IAEs is needed to provide a compatible has implementation, but it'd be a pity to introduce null ambiguity and lose the type safety of these classes. A new query operator might be a better choice...