De : David Sean Taylor [mailto:[EMAIL PROTECTED]<snip>
On Thursday, August 7, 2003, at 09:54 AM, Luta, Raphael (VUN) wrote:
<snip schema>For mt PSML stuff in JS2, I've currently broken down the
persistence
options like this: - PageManagerService:
Function:
Handles page persistence (ie loading and saving pages and
fragments
to storage as well as creating new pages and fragments)
Implementation: I have 2 implementations in the works: - XML/Castor, with XML files on disk (complete, I just need to stop answering mails and write the related unit test files :) - OJB based (through the persistence plug-in) (in progress, 80% complete)
Do you mind if we look at this from the database table view?
I know its a implementation detail, but Im interested in the database end of things, so if you don't mind
Have you had a look at the DDL in the CVS? see create-db-phase2.sql The DDL does not have blobs. I was hoping that the database impl would not make use of blobs...
I don't think blobs would be necessary. I specifically kept a typed fragment class in the OM to be able to store fragments as rows in a single table.
My main concern right now is whether to keep this schema normalized
with the costs associated for looking up an object tree or have a
denormalization fields to speed up fragment requests. I'm not familiar
enough with OJB to see right now if such a denormalization field could
be easily used by OJB.
I see the service as storing something like the PSML_ENTRY table (see the phase2 sql file)
As you can see, it's pretty similar to phase2 except that I'm using varchar for keys instead of INT IDs, for 2 main reasons:
- I wanted to use the impl objects for the time being for both XML
and OBJ
- I want to be able to store GUID/UUID as PK if we move this way.
For the XML files, the default service implementation just write files in a flat directory, with files identified by an id (this is different from JS1 behavior).
Typical directory layout would be: /WEB-INF/pages/ pageID1.psml pageID2.psml pageID3.psml ... pageIDX.psml
- PageRegistryService
Function:
Register available portal pages and map these pages to
user and role
profiles. The API of this service will be an extension of
the default
Registry service
I see this service as storing the equivalent of the PSML table in the above sql fle
Yes, similar but I'm still playing with exactly what attributes/objects I want to include in this registry (this will probably be the subject of another mail).
Implementation: Again 2 implementations possible: - XML/Castor based on the current JS1 registry code (70% complete) - OJB/Persistence plug-in like the new PortletRegsitry written by Scott (0% complete)
With XML implementation, information is stored in one or several xreg files in /WEB-INF/conf by default.
Example of page registry entries:
<snip markup examples>
This setup should IMO be both more efficient in the XML and SQL persistent mode because of the flatter structure and be
more flexible
because the PageRegistry allows a central page repository and some user->page mappings that were not possible in JS1, including the ability to "off-line" a page without removing it physically.
For the file-based system, I see the big difference in that the PSML is not stored in a directory tree.
All PSML is stored in one flat directory area, and a new XML file makes the mapping.
I guess Im not too concerned, since I prefer to store in the DB. But it just makes me wonder about two things: 1. migration. people are used to the directory layout 2. Is this going to overly complicate the simple deployments
I see the file-based solution best for users who need a simple portal that is easy to configure.
The directory layout was very easy to understand.
Concern 1: Luckily it's very easy to flatten a deep directory structure, actually mush easier than moving from one tree structure to
another :)
The PSML migration task will have to perform the following actions
(assuming migration from PSML on disk)
- create a new empty Page Registry (XML or OJB)
- browse the PSML disk tree structure and for each PSML file found:
- register the page in the page registry based on the directory path
- extract the <entry> parameters and store them separately in the
user preferences store (and create a new GUID for this entry)
- transform the current PSML file to the new format through XSLT
- store the tansformed page in the flat page store
The most tricky action here is exporting the user prefs to another store because of the amount of ID messing involved.
Concern 2:
Yes, it does add an additionnal step but OTOH, even when using disk
based persistence I foresee a much greater reliance on tools/GUI
for deployment issues that JS1. The PageRegistry will make implementation of an updated PsmlBrowser both much simpler and more
powerful so there should be really fewer incentives to manipulate
the psml files directly.
To add another point on the PSML XML vs SQL debate:
in the proposed Page OM, the page description is completely user neutral and *never* stores any user-specific information even when
it's shared by several logged-in users.
Because of this, Page caching will be much more efficient and the
portal should very rarely have to update the pages.
That makes page loading performance from storage a much
smaller issue than for JS1 and make the XML viable for larger deployments than in JS1.
I agree with the above.
Concern 3
By using a normalized DB, then JS2 is scalable by adding machines. Although a file system can be shared among machines, a database is a much cleaner, secure, and reliable approach,
-- Rapha�l Luta - [EMAIL PROTECTED] Jakarta Jetspeed - Enterprise Portal in Java http://jakarta.apache.org/jetspeed/
**********************************************
Vivendi Universal - HTTP://www.vivendiUniversal.com: The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material of Vivendi Universal which is for the exclusive use of the
individual designated above as the recipient. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.
Paul Spencer
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
