File Comments Data Structure

[blizzz]

Contributes to #16328

Comment:

• id, INTEGER
• parentid (on replies to comments), INTEGER
• topmostparentid, INTEGER
• children-count, INTEGER
• message, CLOB
• actorid (== userid), TEXT
• actortype, TEXT
• verb (= 'comment'), TEXT
• timestamp, INTEGER
• latestchildtimestamp, INTEGER
• objectype, STRING
• objectid, STRING

The chosen way to identify comments as unread is to keep a "last seen time" timestamp per user and file, which applies to all file activities (like updates). This would be implemented within the Timelime logic and structure (#20259).

In general, a thing to ensure is it that userids are compatible with federation.

@nickvergessen @PVince81 @DeepDiver1975 @jancborchardt

[nickvergessen]

fileid is not always int (depends on the storage)

[PVince81]

Please replace "(Un)read status, per comment version:" with "last read status". We don't want each comment to have a flag. We only need the last read date for each file, so the fields would be "fileid, userid, lastdate"

[blizzz]

@nickvergessen @PVince81 adjusted

[DeepDiver1975]

commantid -> id

[blizzz]

✔️

[PVince81]

• filelid must be string from now on

[nickvergessen]

object type and object id please instead of file id

[DeepDiver1975]

children-count

[blizzz]

updated the encryption. Set the object type to string, is more explanatory than numbers, especially in URLs.

[nickvergessen]

timestamp of last child for sorting?

[blizzz]

yes, added

[blizzz]

If we want to totally keep a hierarchy possible that is deeper than just one level, we'd need to add a topmostparentid in order to be able to cheaply detect the root of the thread. We agreed that in the file comments matter, 1-level depth might be considerable in future. However, this does not need to apply to all possible use cases of the comments infrastracture. What do you think?

[blizzz]

@DeepDiver1975 @PVince81 @nickvergessen ^

[nickvergessen]

Well consensus was to make it possible to have it nested.
But we could also not add it now and then when we ever need it, add it.

[blizzz]

Adding it later does not sound too desirable. If you need to determine those parents for millions of comments upon update. Well, you could skip that and only determine that column on demand and/or specific cli call, but we'd need to carry this load forever. Better we do it now or not, let's do this. In our first implementation, it'll be always 0 anyways.

[blizzz]

we need another field, see https://github.com/owncloud/core/pull/20562/files#r45613011. I'll add it to the description.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.