> 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.
I am thinking about moving some of the current object model in this direction also this also. At least: - PortletDefinition - PortletApplicationDefinition What is really nice is that OJB is very pluggable we can create an ID generator that generates UUIDs for the auto-PKs instead of standard integer values. Regards, *===================================* * Scott T Weaver������������������� * * Jakarta Jetspeed Portal Project�� * * [EMAIL PROTECTED] * *===================================* � > -----Original Message----- > From: Luta, Raphael (VUN) [mailto:[EMAIL PROTECTED] > Sent: Friday, August 08, 2003 4:42 AM > To: '[EMAIL PROTECTED]' > Subject: RE : J2 PSML persistence > > > 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]
