D
Daniel Pitts
So, we want to have two different instances of the same "entity". One
is the "working" copy, the one that our editors are working with. The
other is the "published" copy, the one our front end users see.
Our solution has been to have two identical DB schemas (content,
content_preview), and then have our tool copy the appropriate rows out
of content_preview into content when its time to publish.
This "works", but it has a lot of caveats, and I'd like to know if there
is a better way to do this? Performance of the "published" copy is an
issue, space less so.
Different approaches I can think of:
1. Two identical Schemas (What we have currently)
2. Every table foo has a foo_preview. (Similar to above, harder to
handle in Hibernate)
3. Every column foo has a foo_preview. Probably we would need a special
"previewable" embeddable entity, and a way to "globally" specify whether
the default value should be preview or not.
4. Every entity ID has a "revision" number, and a table with a
"publishedID->revision" mapping. Requires a composite key on our
previewable entities (ID&Revision), and an extra join when looking up
live data.
5. Store preview data in a completely different manor (serialize and
pass to the preview app)
6. A. Collect underwear, B. ..., C. Profit!
Anyone have suggestions about any of these methods, or another approach
that I've missed? I'm personally leaning toward 4, or sticking with 1.
The problem with 1 is that in order to CRUD on the live version, you
need to do some ugly hacks in Hibernate.
is the "working" copy, the one that our editors are working with. The
other is the "published" copy, the one our front end users see.
Our solution has been to have two identical DB schemas (content,
content_preview), and then have our tool copy the appropriate rows out
of content_preview into content when its time to publish.
This "works", but it has a lot of caveats, and I'd like to know if there
is a better way to do this? Performance of the "published" copy is an
issue, space less so.
Different approaches I can think of:
1. Two identical Schemas (What we have currently)
2. Every table foo has a foo_preview. (Similar to above, harder to
handle in Hibernate)
3. Every column foo has a foo_preview. Probably we would need a special
"previewable" embeddable entity, and a way to "globally" specify whether
the default value should be preview or not.
4. Every entity ID has a "revision" number, and a table with a
"publishedID->revision" mapping. Requires a composite key on our
previewable entities (ID&Revision), and an extra join when looking up
live data.
5. Store preview data in a completely different manor (serialize and
pass to the preview app)
6. A. Collect underwear, B. ..., C. Profit!
Anyone have suggestions about any of these methods, or another approach
that I've missed? I'm personally leaning toward 4, or sticking with 1.
The problem with 1 is that in order to CRUD on the live version, you
need to do some ugly hacks in Hibernate.