Improve Facets mutation handling

[willcj33]

Currently, if I write a facet like so <n1> <pred> <n2> (fromMerge:true) . and then afterwards, another process "upserts" the same two nodes and edge like so <n1> <pred> <n2> ., the fromMerge boolean facet is removed.

If I don't alter the facets in any way, would it make sense to not delete them? It would make managing edge facets easier on us, or at least allow an option to NOT overwrite the current facets.

This is currently an issue for us because when the fromMerge is written, there are specific things that only ever happen in that context that no other process that upserts items knows about. Thus I continue to lose that facet, which is used for specific and critical actions down the road.

Using 1.0.1 and the Golang Client.

[MichelDiz]

I believe you should instantiate the data from Facet. For the idea behind the Facet is to have a "status" of that information. As an extra, but not as a immutable. So if you change it, the status should be changed too. Or in that case, deleted. if you want to keep or refresh the Facet you should control this in the application as if it were a pipe.

That's my two cents.

[pawanrawal]

This is more complicated than I expected. My advice would be to fetch the facets first before upserting for now. Implementing this properly will take some time.

[manishrjain]

So, if we have round brackets, then merge. If no round brackets, delete facets.

[jimanvlad]

Is this likely to be implemented base don @manishrjain 's suggestion above?

[manishrjain]

We'll definitely work on this, no exact timeline yet.

[MichelDiz]

I think an "append" operation should solve the case. Perhaps in cases of KV overwriting we should have an alert preventing the mutation. Or maybe just overwrite it.

Who self-assign? @srfrog , @codexnull , @gitlw , @mangalaman93, @martinmr ?

[AlexanderCHarrington]

Has there been any decision on this?

[lelvisl]

Some updates?????