NoSQL: Metastore implementation

[snazy]

No description provided.

[dennishuo]

Still want to take a closer look at the rename/move logic, but the basic updateIfNotChanged flow looks good to me.

Left some initial comments. In general, it would be nice to expand javadoc comments whenever there are implicit format/parsing conventions defined in code, such as in the GrantTriplet (or class javadoc can link to wherever it's explained elsewhere if I just didn't see the file where it's documented).

[dennishuo]

All the other factory methods are mostly self-explanatory, but this one could use some javadocs explaining what locationString is, expected format, etc.

[snazy]

yup, added

[dennishuo]

Is this really intended to support all chars with ascii codepoint > ' ' or is there a more intuitive regex? In particular, though I don't know all ascii codes offhand, a cursory search seems to indicate for example that 127 is the "Delete control character" even though it comes after all the basic symbols and letters.

Maybe Character.isJavaIdentifierPart will help provide a better standard constrained set while also making it easier to reason about when reading the code.

[snazy]

This identifierFromLocationString is used (only) for location-overlap handling, assuming that the storage locations are already validated. Adding assumptions here about the actual format of object-store specific conventions or valid file-path chars feels a bit too risky?

[dennishuo]

What are the scenarios that can lead to this byName not having this originalNameKey that we just got from byId? Would it indicate byId and byName getting out of sync somehow?

[snazy]

There's no thinkable scenario actually.

[snazy]

Ideally I'd prefer to not have the byId index at all and just refer to entities by name.
But that requires a bigger change.

[dennishuo]

Please add javadoc comment for this one explaining intent and how it intends to canonicalize whichever fields for comparison.

Is this to detect cases where a real update actually happens to result in an entity whose full contents are unchanged, or is there a common concurrency situation that is expected to cause "no change" mutations (e.g. on some kind of retry?)

[snazy]

It's to detect whether a update is actually changing something.

[dennishuo]

Does this mean that if someone does craft an update request which happens to be a no-op, that we'll skip the database write, meaning:

1. The updateTimestamp won't change
2. the entityVersion won't change

but event and audit-logging features would still show a successful update at the new timestamp? I can't remember if the current AtomicOperationMetaStore/TransactionalMetaStores do anything similar, or if this is divergent behavior.

[dennishuo]

Overall LGTM. I'm not sure about how the "skip no-op updates" optimization if it's divergent from the existing persistence impls and what it would mean for discrepancies between audit logs and updatedTimestamp in persistence, but I'm okay just revisiting that discussion later or in a followup

[snazy]

Thanks for the reviews!

not sure about how the "skip no-op updates" optimization

I think, it depends on the, say, "interpretation" of what's an update.