[opencms-dev] Data management for multi-domainregional customerportal

[Jonathan Woods]

Christoph -
 
I see what you're getting at, and I understand that you want to do things
the 'right' way.  However...
 
1.  I believe that modifying the OpenCms database structure is the wrong way
to go.  Your modifications would have to be very deep to allow database
referential integrity to work, and therefore (i) it would take you a good
deal of time to understand the OpenCms structure and how it's used, (ii) it
would take you a long time to modify that structure safely, (iii) it would
make your solution extremely brittle, in the sense that fixes or upgrades to
OpenCms couldn't be reapplied without at least a good deal of testing on
your part, and more likely a good deal of reimplementation.
 
2.  Storing anything in OpenCms document properties doesn't give you any
kind of RI either, because their contents are just strings.
 
3.  Re the issue of checking/changing 'legacy' data in the face of metadata
changes: that's always going to have to be done, however the two are linked.
You're going to have to implement the checking/changing at the application
layer in any case (unless you rely solely on error messages coming up from
the database layer!), so why not implement RI there too, and leave the
database layer as it is - largely agnostic to document structure?  After
all, RI at database layer is often illusory - it's always possible for an
application layer to make attributions of values which are in some way
nonsensical, even if strictly speaking they're valid according to some
relational schema.
 
Jon
 
  _____  

From: opencms-dev-bounces at opencms.org
[mailto:opencms-dev-bounces at opencms.org] On Behalf Of Christoph Schönfeld
Sent: 16 October 2006 09:21
To: The OpenCms mailing list
Subject: Re: [opencms-dev] Data management for multi-domainregional
customerportal


Hi,

thank you for your detailed reply, Jonathan.

What kind of metadata do you store in the dedicated XML content type?

If one does not use the OpenCms document properties the metadata needs to be
stored and maintained separate from the documents which sounds like a source
of error. There is no integrity checking for the links from metadata files
to documents. Secondly, there are two points of change/approval for every
new document that is created: the document itself and the metadata document.
The latter will be a concurrency bottleneck in my multi-user scenario.

At first, I had planned to store just the metadata definitions in XML files
and refer to them in custom document properties. It would be easy to build
upon and extend OpenCms's integrated search functionality then. I would
create document properties for topic (main menu structure) and subtopic (sub
menu structure) for example. 

However, this approach does not provide automatic referential integrity
checking either. For the case of change to metadata definitions the existing
documents would need to be checked/changed. If the metadata document is an
OpenCms document as well I can not prevent that it is being edited directly.

When I think about all these problems I think it's quite easy to produce a
mess that way and rather tend to put all metadata in the database. It comes
with free RI checking. It makes upgrades a bit harder but not impossible. I
will have to implement the OFFLINE/ONLINE mechanism myself. Perhaps I can
reuse or extend the OpenCms code to synchronize my own OFFLINE/ONLINE
tables.


Christoph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20061016/4f2784a3/attachment.htm>