There has been some talk about persisting the layout structure as pure XML in the DB. We'd strip off all unnecessary attributes so that you'd only have <folder id=""> and <portlet fname=""> elements in the XML. After loading that DOM the rendering pipeline would then add all the necessary attributes to each element based on its ID and other parameters. The two down sides of this approach is we can't add referential integrity in the DB from folder IDs to attributes so making sure there aren't orphaned attributes in the DB would be more work and you wouldn't be able to run queries against a user's layout, that would all have to go through tools written against the layout manager DAO.
Part of that decision will be based on what support JPA2/Hibernate has for persisting an XML Document object. It would be good to write as little custom code around that solution as possible but I'm not really familiar with what the options are there.
-Eric On 2/13/11 8:07 AM, Eric Dalquist wrote:
That code hasn't really been touched in trunk. It is on the list of things we'd really like to clean up and get moved into a better service/dao/data model setup but we can only do one chunk and a time and taking on the layout management code isn't a trivial task. I'm hoping we can get to it for 3.4, create a strongly typed data model, use JPA2 for all of the persistence and move all the DLM logic into a single coherent service layer instead of being spread across the layout store, layout manager, and layout classes.-Eric On 2/10/11 10:18 AM, Gary Weaver wrote:We recently got into a situation where we were able to get a few new portlets, a new layout user, and new fragment working in one environment's DB, but not in the target environment's DB, and it is a mess to diff these (even with table exclusions, etc.) because layout user data is mixed up with other user data and their changes to user-specific layouts and preferences in the schemas. This is DLM but a much older version of uPortal, and the issue we are having is not something that would typically be a problem for most, but I've started to wonder whether this data is better separated in uPortal 3.3?I understand that schema changes are not to be taken lightly, as the ease of upgrade and speed and efficiency of DB operations are much more important. But, maybe if user and group layout data are still entwined in uP 3.3, is there any chance that group layout/fragment data and user layout data is at least maybe a little easier to follow in the latest uPortal? If not, could schema changes to make it easier to manually restore group layout/fragment data be considered specifically for a future major release if it didn't significantly affect performance? Really sorry if this sounds lame.Thanks, Gary
smime.p7s
Description: S/MIME Cryptographic Signature
