-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How do we deal with a Unit's unpinned references to components when those components are soft-deleted? #219
Comments
Can I get some clarity on this? Lib component Alpha version 1 is published If I'm understanding correctly, I don't think we need to work too hard to support this case. I think users would understand if they're now stuck on version 2 even though it wasn't the last published version, because the whole thing has been deleted upstream. And if it were really important to upgrade to version 3, the library author could un-delete it. |
@bradenmacdonald: I think I'm going to close this one as unnecessary anyway, but to give more clarity: This is mostly relevant to relationships between Components and Units within a Library and eventually within a Course, not really across a Library -> Course borrowing in the short/medium term. The "let the version float" convention we were talking about–where
But in that data model, it's possible that one of those Components that the Unit references becomes soft-deleted. If that happens, we can get into a situation where the Unit has effectively lost that Component (floating to the draft or published version will bring back a null entry). So I was briefly thinking that we would also store the last published version before it was deleted, and that might be useful in scenarios like keeping a SlotVariant's links working in the "delete a thing from the random pool" use case. But after a bit of reflection, I think it's better if Units (and other container types) listen for when one of their child elements are deleted and force a new |
Oh wait, but even if the new UnitVersion is right in that case and accounts for the deleted Component, the previous UnitVersions will all have the null references. Unless creating a new UnitVersion somehow freezes the ComponentVersion links of the previous UnitVersions? Or maybe it could store the whole range?
So then I think I need to kick this around more... |
Unfortunately, that idea above about locking when a new version is created would complicate publishing and reverts. For example, if a new version of a Unit is created but not published, it would be wrong to lock the I'm assuming that Components can live in multiple Units. If Components associated with Units are always copies + references (like they are between libraries and courses), then this becomes simpler. Maybe that's the angle to go with... |
Okay, I was sketching this out in a notebook over Korean BBQ this afternoon, and I think it's a lot simpler than I was worried it would be. The simpler representation where we just have the nullable foreign key to the version should still work, and reverts should still be simple, as long as:
I thought (2) was going to be hard, but at the moment the only way to publish a delete is to publish everything (because you can't access a "publish" button on a deleted thing), so the Units would come along for the ride. But if we ever do give a separate "publish the deletes" button, we should make sure the referencing Units get published as well. (I think this means we should have a "Trash" page for things that are going to be deleted in the next publish–but maybe that can be covered by a generic "preview list of things that will be published if you press this button". It would also be nice to be able to "undo" a deletion without reverting everything to the published state.) |
Oh wait, it works if you're only ever looking at the state of things that are published, but it wouldn't necessarily work for a situation where you had something that was linking directly to an older version–say you had Student state that you wanted to fix to a That would complicate two things:
Though there could be workarounds here too. Reverts would need a little extra housekeeping and complexity, but it's doable. We could bypass issues around scaling if we make the convention that any container type made for a specific user must have all the versions pinned from the start. This is feasible for a few reasons:
|
The latest version of this is being captured in #240 and I'm closing this Issue in favor of that one. |
Is it worth adding more metadata to the
Published
table to cover use cases where something has been soft deleted (e.g.last_version_before_deletion
)? This came to mind when I was thinking about what happens if we use the "a null version pointer means take the latest draft or published" convention and then soft-delete+publish a Component that was being referenced. Do we always want to carry over the deletion, or do we sometimes just want to lock to the last valid version?This information is derivable from
PublishLogRecord
(find where the entry for thisPublishableEntity
gets itsnew_version
set tonull
). But that's slower to access for the "get a big list of components" scenarios.(This came up tangentially in this comment w.r.t. how Slots in Units might change over time, e.g. someone deletes a Component from a pool of possibilities to be randomly selected from.)
The text was updated successfully, but these errors were encountered: