De : David Sean Taylor [mailto:[EMAIL PROTECTED]
> On Thursday, August 7, 2003, at 09:54 AM, Luta, Raphael (VUN) wrote:
> > 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.
Thus the schema (normalized) can look something like this:
TABLE PAGE
(
PAGE_ID VARCHAR(32) PK,
PAGE_TITLE VACHAR(128),
PAGE_SKIN VARCHAR(128),
PAGE_ACL VARCHAR(32),
)
TABLE PAGE_DEFAULTS
(
DEFAULTS_PAGEID VARCHAR(32) NOT NULL FK PAGE(PAGE_ID),
DEFAULTS_FRAGMENT_TYPE CHAR(1) NOT NULL,
DEFAULTS_DECORATOR VARCHAR(128) NOT NULL
)
TABLE FRAGMENT
(
FRAGMENT_ID VARCHAR(32) PK,
FRAGMENT_PAGE_ID VARCHAR(32) NOT NULL FK PAGE(PAGE_ID),
FRAGMENT_PARENT_ID VARCHAR(32) FK FRAGMENT(FRAGMENT_ID),
FRAGMENT_TYPE CHAR(1) NOT NULL,
FRAGMENT_NAME VARHCAR(128) NOT NULL,
FRAGMENT_ACL VARCHAR(32),
FRAGMENT_DECORATOR VARCHAR(128),
FRAGMENT_SKIN VARCHAR(128),
FRAGMENT_STATE CHAR(1),
FRAGMENT_REF VARCHAR(32) FK FRAGMENT(FRAGMENT_ID)
)
TABLE FRAGMENT_PROPERTY
(
PROPERTY_FRAGMENT_ID VARCHAR(32) NOT NULL FK FRAGMENT(FRAGMENT_ID),
PROPERTY_LAYOUT VARCHAR(128),
PROPERTY_NAME VARCHAR(128),
PROPERTY_VALUE LVARCHAR
)
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.
--
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
