I do have a couple of local issues where we'd like to run reports against user layouts in order to understand what our user base has customized. Most of the need is not time sensitive, so calling upon an API would probably be okay. The only thing I could see vaguely being time sensitive is the notion of a portlet that ranked the popularity of other portlets, but even that could run in the background and be cached.
For no good reason, other than having been bitten by another system here used to store its data as XML in a database, I've not been a fan of that approach, but you folks are far more current on the issues than I am. That system here that stored XML had lots of trouble trying to support reporting later. It couldn't match the flexibility and speed of a database query. On Sun, Feb 13, 2011 at 9:17 AM, Eric Dalquist <eric.dalqu...@doit.wisc.edu> wrote: > Also a good question for deployers to think about is what would be a good DB > schema format. The current UP_LAYOUT_STRUCT table is quite complex because > it is representing an arbitrary XML document in a table and tree <-> table > isn't exactly a simple thing. > > 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 >>> >> > > -- Bruce Tong Software Engineer Office of Information Technology Ohio University -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
