Topic on Talk:Multi-Content Revisions/Database Schema

<code>slot_inherited</code> versus <code>content_origin</code>

5
Summary by Daniel Kinzler (WMDE)

We prefer a boolean slot_inherited over full content_origin.

Anomie (talkcontribs)

In retrospect, while doing this on-wiki versus in Gerrit made it easier for you to add implementation notes, it makes it harder to comment on things. Flow makes it even more of a pain.

slot_inherited seems more natural to me. A content row could theoretically be reused for later revisions. For example, if someone makes and edit and that edit is reverted using the rollback feature, we're probably going to take advantage of that trivial case to reuse the old content row. With content_origin, though, we'd either be prevented from doing that because we'd have to update the origin or the existing origin would cause the slot-history thing to skip showing the revert.

slot_inherited would also be more efficient for your proposed use case, since it won't require joining the content table to determine whether a revision can be omitted.

Daniel Kinzler (WMDE) (talkcontribs)

I'm also leaning towards slot_inherited for practical reasons, though content_origin retains more information.

Daniel Kinzler (WMDE) (talkcontribs)

...and yes, using Flow for this discussion is a bit painful. Inline would be better... I'll think about it.

I really want inline notes for wiki pages! But where do we store them? I wish we could just attach additional content objects to a page... ;)

Anomie (talkcontribs)

The bigger trick with inline notes for wiki pages would be in not losing them when something else in the page is edited.

Daniel Kinzler (WMDE) (talkcontribs)

We could just switch to HTML for primary storage, then we wouldn't even need MCR for the inline notes :)