Issues with tinkerpop implementations that support FEATURE ignoresSuppliedIds = true

[ramukima]

On a graph implementation where Graph.FEATURES.ignoresSuppliedIds is set to true, the 'update' on existing subgraph causes new '_id' to be generated. That means, the caller will have to use this new '_id' next time to load the subgraph and update again..

One option is for the writer to ask for creating a 'uniq' property with a random unique generated value. e.g. uuid = UUID.generateRandom() and add it as a property to every model object when it is constructed.

However, would it make sense for this library to allow specifying a 'properties' setter callback which is invoked before any of the 'important' properties are set on a vertex by vertex mapper.

This will allow callers to be able to set default values for one or more properties of a vertex.

[jkschneider]

One of the principles of pappus, and I need to document this better, is that subgraphs are immutable. Loading an object model from the graph, modifying it, and saving it, results in some new subgraphs being generated without touching the original ones. Where portions of the model haven't changed, edges are drawn to existing subgraphs.

There are a series of methods on GraphObjectMapper to allow the user to configure the names of the special properties used by pappus, as documented here:

https://github.com/jkschneider/pappus-graph-projection/wiki/Type,-Index,-and-Hash

I'm hoping that I understood the question well enough. Does this answer it?

[ramukima]

Understood the immutable aspect. However, for a caller of an application which uses this library, changing the 'unique' identifier of the object they are trying to modify results in confusion, and the caller has to note down the new id.

I also understand that, ensuring that the unique identifier of an object being updated does not change can be the responsibility of the application (and not this library). e.g. inject a unique identifier at the time when the subgraph was originally created and make sure and make sure that this unique identifier gets copied into the 'being updated' subgraph at the time of update.

However, if this library could provide a hook to initialize those defaults (other than the critical properties managed by this library), that would be helpful. Does that make sense ?

[jkschneider]

I think I understand where you are coming from now, and have thought this myself. This is especially troubling when the model does not have natural primary keys. I'll need to think about this a bit more.