[ADDED] KeyValue and ObjectStore support for JetStream

[derekcollison]

Also:

• Fixed message reply in PublishMsgAsync
• Ability to seal streams
• Ability for consumer to get message headers only, no msg payload
• GetLastMsg and purgeStream by subject

[coveralls]

Coverage decreased (-1.9%) to 84.89% when pulling 141643a on kvo into 4e70dbe on main.

[ripienaar]

looks good in general, a few comments of things the ADR covered and deviations on ADR design

[aricart]

Part of the reason why KvEntry is OK is that it is effectively a StoredMessage, with additional metadata about the bucket and the operation. With that said, I would much rather have a presentation where such values are in the headers. But there we get into additional issues: headers from the system may collide with user headers, and if the user sets a header that collides what is the meaning of that.

For replication and watches, the understanding of DELETE as an operation is important. Empty is really open to interpretation. The store could a have value by simply indicating that the key exists, thus the need for the operation to be telegraphed.

Outside of applications that deal with replication or that need to do something special on delete, the absence of the value is simpler. For NGS, my KV wrappers actually hide all the unpacking and simply code DELETEs as a null return value (ie I don't differentiate). But In some cases for example where keys should have a TTL, it is important to know the value doesn't exist even if it did.

TBH - I would rather see the ADR extended to deal with blobs and perhaps provide a compare and swap based on value, but understand that this is not what the nats-server is doing.

[aricart]

Does Put fail if the key doesn't exist? - IE looking for clarification between Create and Put wondering if what we are trying to accomplish here is some sort of compare and swap.

[scottf]

In the ADR, there is no create, just put, and the behavior is create or replace

[aricart]

would Init be more indicative than Create?

[derekcollison]

Create only succeeds if not present, Update only if it is present and has not changed, and Put just works all the time sans other issues.

[derekcollison]

I believe they should all have this functionality.

[ColinSullivan1]

With respect to the object store we should allow the design to support features (external or internal) such as:

Lifecycle Management (delete, TTL)
Event Notifications (add/delete/lock)
Locking
Archiving (tiered storage)
Searching/Indexing (tagging)
Versioning

With the proposed design it seems that all of this could be possible through an external system (primarily via object nomenclature) while keeping functionality as simple as possible here. Just want to avoid making it difficult to build a future feature due to a design decision today.

[derekcollison]

Lifecycle Management (delete, TTL)

• We have TTL, but not explicit delete, can add though the delete.

Event Notifications (add/delete/lock)

• We have these in general for streams (sans lock/seal). @ripienaar can confirm

Locking

• I did a soft seal so to speak as we discussed. Would need for formalize to avoid deletes of messages, purges etc.
• That can all be done now with perms but I think seal would be good eventually.

Archiving (tiered storage)

• That is way bigger then just object stuff, that is a whole core JetStream thing.

Searching/Indexing (tagging)

• Tagging maybe if we promote to stream itself.
• Indexing feels external as we discussed.

Versioning

• What do you mean here?

[derekcollison]

ok I pushed updates to KV. Will do small update to Object in a bit for versions and Purge as well, etc.

[kozlovic]

@derekcollison Following the PR with the FC fix, this PR has now conflict that will need to be addressed. We need to be careful in reverting your FC changes that we are not putting back the way it was prior to the FC fix PR :-)

[wallyqs]

I think maybe we should update the interface to have the partial opts like:

Suggested change

	func (js *js) CreateObjectStore(cfg *ObjectStoreConfig) (ObjectStore, error) {
	func (js *js) CreateObjectStore(cfg *ObjectStoreConfig, opts ...JSOpt) (ObjectStore, error) {

so that later on can pass the arguments below for example like: js.AddStream(scfg, opts)
That would make it possible to change the timeout or context for example.
(This could be addressed in a different PR but before tagging the client to not break the interface)

[derekcollison]

Doesn't that duplicate what we inherit from the js receiver when you setup JetStream context originally?

[wallyqs]

In case of MaxWait it would override what was inherited from the default in the JS context, but for nats.Context option with a timeout for example, those generally passed via arguments like CreateObjectStore(cfg *ObjectStoreConfig, nats.Context(ctx))

[ripienaar]

some general comments for the call today