Re: DataBase Content Repository Implementation (Lenya 2)

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