Ask HN: How do you implement production-grade draft isolation in Django?
1 comments
Instead of a completely separate DB or logic in each view, have you considered:
a) separate managers for live and draft?
b) proxy models for live and draft with separate managers?
c) live and draft child models of the same abstract base model?
But also: Django supports routing between multiple databases.
A third option would be to have multiple instances running with different settings off the same codebase.
a) separate managers for live and draft?
b) proxy models for live and draft with separate managers?
c) live and draft child models of the same abstract base model?
But also: Django supports routing between multiple databases.
A third option would be to have multiple instances running with different settings off the same codebase.
Hit a wall with preview.
Instructors don't want a fake preview.
They want to actually take the exam they just built — real timer, real submission, real grading, state persisted across requests — then either publish it or throw everything away.
Looked at three options.
PostgreSQL schema separation is conceptually the cleanest but Django migrations get painful fast.
is_draft flags end up as conditionals in every layer.
Snapshot tables can't run real workflows.
What I actually want is pytest-style DB isolation in production.
Persistable, discardable.
Does this exist? How do systems like this usually handle it?