Investigate create/modified by/at attributes

[snazy]

It could be useful to expose the following attributes for Nessie Content:

• created by
• created at
• modified by
• modified at

One option ("A") could be to add these attributes to Content (but only update those on the server side). On the pro side, the information is directly accessible, but only available for content that has been created/modified after this change has been introduced.

Another option ("B") could be to derive this information from the commit log. This would work for all existing content.

An open question would be what should happen when new content gets merged: Should the merge set the created at to the merge timestamp? Should the merge set the created by to the user performing the merge?

Another open question (for option "A" mainly): should it store the created/modified commit-IDs? If yes, should the "created commit-ID" also be reset wrt to the above question?

The overarching question is "how important" or better: how often that information is needed/requested. If it's an infrequently accessed information, then it's probably fine to scan the commit log.

[snazy]

@dimas-b @adutra WDYT?

[dimas-b]

Should the merge set the created at to the merge timestamp?

I'd think the "created" timestamp should be a min("created" on merge source branch, "created" on target branch).

[adutra]

Could we get a mix of option A and B? E.g. store the new attributes when writing (A), but when reading, if the content does not have the new attributes, then fetch the commit log (B).

Should the merge set the created at to the merge timestamp? Should the merge set the created by to the user performing the merge?

I'd say yes. We'd lose the original timestamp and user from source branch, but one can retrieve that info by looking into the source branch history.

Otherwise, we could introduce 2 new attributes: merged-at and merged-by. But if the content gets merged many times to several branches, we'd lose the intermediary merged-at and merged-by info anyways, so not sure this is worth it.

If it's an infrequently accessed information, then it's probably fine to scan the commit log.

If these new attributes get included in the events API one day, I'd note that this info would be accessed for every content modification. This makes me nervous about the option of scanning the commitlog.

[dimas-b]

If these new attributes get included in the events API one day, [...]

I'm not sure these new attributes are useful in events. The "created" timestamp looks like a user-level helper attribute to me. At the technical level, it is too vague, I think, for events.

At the same time the "modified" timestamp can already be deduced from the event type and timestamp.