Hi Rainer, Vik, Michael, Florent,
thank you all for your valuable and encouraging feedback!
Note: all my ideas and proposals are based on just my(our) experience until now.
WHY NOT JCR?
ATM mainly because I've no 'real' experience with JCR yet.
Some years ago (I think it was with one of the Lenya2 beta releases) I started
and experimented with a JackRabbit repo implementation. Read and write of
content was more-or-less working.
I got the impression and am still of the opinion that this kind of (content)
storage really would be the most suitable and flexible for Lenya - at least in
theory ;-)
To be honest, I'm not up-to-date in regard to really good and powerful
(OpenSource) JCR repositories.
(One colleague told me that they have bad performance issues with the their
commercial CMS. It is using a JCR repository which is the bottleneck. But I
don't assume that this is an issue in general when using a JCR repository for
publications with many ten-thousands of documents.)
IMO the database approach does not exclude any other repository implementation
at all.
The question is, if such an implementation(DB)is suitable at all and if the
benefits are worth the required effort.
I think it would really be a great benefit to have the choice between different
content storages and I assume that there will never be a solution that perfectly
fits for all needs.
WHY SQL DATABASE?
Since many years I've used different sql databases as data storage. Today it
seems to me that getting a sql database in real world applications and
environments is really easy.
In general I'm happy with the way Lenya2 deals with the content. The structure
is clear and in most cases easy to understand. And last but not least good to
know that there's always the option to do changes directly in the content
repository (filesystem) - sure, sysadmins only.
I thought about a 'simple' way to achive the things I mentioned in my previous
mail.
So it was somehow nearby for me to think of a database solution.
ORM FRAMEWORK:
Not in the beginning; I've no experience with this but it sounds promising.
DATABASE STRUCTURE:
It seems to me that the areas authoring, trash and archive are all part of the
"Authoring". Within these three areas (together) uuid+lang is unique (yes?)
In my opinionit's somehow a logical unit of data ('Authoring' in contrast to
'Live').
SITETREE:
I do not have the impression that the sitetree (handling) as it is now is a
performance killer, so I would keep it as-is and put the sitetrees in the
'document' tables with a special uuid like
'sitetree-authoring|trash|archive|live'.
METADATA:
sorry, column 'metasetkey' was misleading and does not make sense at all.
Each metadata set will get a dedicated table (to be precise: 4 tables. Authoring
and Live plus the additional ones for the revisions in each area)
Best regards,
Gerd
