Hi Gerd,
just a couple of comments off the top of my head...
I wasn't present at the lenya meeting in Freiburg (I intended to be there, but
developments at the office kept me busy since summer).
You write:
> Basic:
> 1) available as an alternative to the current file based repo
> 2) It should be possible to choose the repository for each publication (no
> switching between repositories, afterwards)
That precludes the possibility to convert an existing publication repository to
the database based repository - a feature that would by extremely interesting
for existing publications. So, I'd like to have an import/export function.
Regarding the advantages, it seems to me that a database is easier to backup
and
restore than the current file based repo: the repo must not change during the
backup run (which can take some time for a large repo). OTOH, database backup
procedures have this built in.
Concerning The Database structure:
I don't see the sitetree mentioned. Surely the sitetree is one of the important
data structures of the lenya repo and must therefore be implemented in your
database structure. A simple adjacency table with two columns (parent,child)
referencing uuids might do the trick - but I'm not sure how revision control
for
the sitetree would fit in.
> "documents" in this context is mainly what is curently stored in the uuid
> folder
> with filename {language}
> 1) one database per publication
> 2) Documents table: one table for the documents in the Authoring (also
> contains
> Trash and Archive) and one table for the documents in the Live
I wonder: why this distinction, which complicates the mapping from the repo
structure to the db structure? Why not have one table for all areas or one
table per area? Performance?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
