Artifacts metadata

[olenagerasimova]

• Let's implement some mechanism to store artifacts metadata, like:

• repository name

• artifact name (unique)

• artifact version

• created date

• size (size of the package itself, external metadata/checksums files not included)

• username of the user who uploaded the artifact

Questions:

• what will happen with the record if the artifact was removed?
• what will happen if the artifact was updated/replaced?
• what db we will use and will the table be somehow partitioned?

What to implement:

• interfaces/classes to write the info listed above into db
• pass authorized username into header to origin slice in AuthzSlice: now adapters are not aware of the user, who is uploading the artifact
• call this new mechanism which adds records into db inside each adapter

Steps:

• pass authorized username into header to origin slice in AuthzSlice https://github.com/artipie/http/pull/541
• implement mechanism to gather and process events queue https://github.com/artipie/http/pull/542
• add database integration and events queue feat: added consumer and tests #1295
• gather events in adapters
• update adapters in artipie feat: artifacts metadata event queues #1312
• add tests feat: IT for metadata events #1313
• fill metadata db from some existing artifacts storage

[olenagerasimova]

@dgarus please, take a look and let's discuss my questions

[dgarus]

@olenagerasimova @ChGen

what will happen with the record if the artifact was removed?

I think we have to remove the referred record.

what will happen if the artifact was updated/replaced?

Update the according record.

what db we will use and will the table be somehow partitioned?

Suggest SqlLight.
I think we could do optimizations when it will be needed.
In any way, this is artipie's internals, and we can change it at any time.

[ChGen]

Agree, we should provide some interface to the adapters, so Artipie would be able to add/update/remove records from the index database to keep it relevant.
I think SQLight would be enough for starters. As I remember, it could be slow if insert operations are done in straightforward way (without transaction & etc.), so it could be easily fixed.

[olenagerasimova]

@dgarus @ChGen
do I understand correctly, that we do not wait for this insert into db operation to complete before returning response in slice? If repository update operation is successful, but insert into db failed, we reply OK and simply log the error about the db insert failure?

[github-actions]

Issue is stale, CC: @artipie/maintainers