Publish side effects: state summary edition #328
Conversation
|
@ormsbee How are you feeling about this PR? |
|
I'd like to pick this back up this week, probably on Thurs or Friday, and get it to a mergeable state early next week. |
|
@ormsbee Friendly ping on this since it's blocking our PR openedx/frontend-app-authoring#2186 . Let us know if we can help in any way. |
Create the PublishSideEffect model as the publishing analog for the DraftSideEffect model, and create these side effects for parent containers when one of the children is published. This allows us to efficiently query when any subtree of content was affected by a publish.
ormsbee
force-pushed
the
publish-side-effects-2-state-summary
branch
from
e8cf989 to
3bbe4f7
Compare
|
I've been hacking at this and I've decided to close this in favor of a new PR with a simpler approach. In particular, I realized that the original approach I had here of separating Draft and Publishing dependencies would deprive us of historical information that would be necessary if we ever wanted to do "rollback to this version" functionality. Instead, I've created a new branch that makes a single This does increase our storage use because it captures dependency information at every version of a container. But I think that's acceptable, as it's smaller than the rest of the container version metadata. It also folds the implementations of the published and draft state calculation to be closer to each other. I've already converted the dependency calculation and side-effect generation code. I still need to redo state calculation and "publish dependencies" functionality, and then I'll open the new PR. |
2 participants
Attempt to reimplement #307 with the ideas from #317