Attendees
Tim Carrol, Andy Gherna, Drew Wills, Eric Dalquist, Chris Holdorph, Jay Patel, Susan Brahmhall, Jeff Dimpsey, Andrew Fitzpatrick
Notes
Agenda note about synthetic IDs in layout export files
Drew:
Enhancements from early 2009 on layout export and import support.
Yale has used DLM for a few years and has had all features enabled and it is used a lot by their users. They end up having a lot of DLM customization data.
Until early 2009 the support for this data was minimal in the export tools.
Early 2009 work with Yale was focusing on using the existing Java code in DLM to help with layout import/export and also bring the exported layout XML file format in-line with the actual in-portal data model.
Susan:
That the only way to get complete export coverage was to use the DLM code itself instead of trying to reproduce the logic in the export scripts.
Drew:
Exported data and imported data using snapshot of 3.2
Eric:
Talking about the 2.5 and 2.6 export releases are based on the 3.0 export code.
Susan:
Points out that we need to backport the 3.2 export code to 3.1, 3.0, and 2.x so that complete DLM export support exists.
The issue with the layout files is the format had to change in 3.2 to make complete support for DLM layouts.
Susan:
Asking about doing more 'diff' style support for upgrades, where it makes minor changes to the existing database.
Tim:
What about portlet preferences?
Eric:
Those are handled in .channel and .layout files
Drew:
Asking about end of service life for 2.x
Eric:
We can't drop export support for 2.x and right now there is no good way to upgrade from 2.x without losing data.
Drew:
The layout import/export changes that were made in trunk also includes Java code changes to the DLM code which would need to get brought back to the previous uPortal versions.
Susan:
Yale has some 2.x code to export complete DLM data.
Drew:
We need to look at backporting this model and import/export into 3.1 and 3.0 to address what is really a bug. The 3.0 and 3.1 code would still be able to support a 2.6 layout file.
Tim:
Would a tool to tell you the upgrade path be helpful?
Eric:
You just need the latest versions of your source and destination versions, the upgrade code handles intermediate versions.
Drew:
Leapfrogging versions works and the import code handles transforming the old entity files into the new format.
Susan:
Interesting in talking about how this can change so we don't have to export and import.
Eric:
The hard part with partial upgrade support is the constraints that the JPA managed object model in uPortal does not allow piece-meal changes. Due to foreign key constraints it is difficult to only export/import part of the object model.
Jeff:
Would it be possible to write a SQL script to do a piece-meal upgrade?
Eric:
Yes, this is possible. It just isn't something that we've decided to focus on due to the variety of databases that uPortal supports.
Susan:
At the moment it feels less risky to do a piece-meal upgrade versus full export and import.
Drew:
Synthetic ID support in layouts for DLM. If you have a bunch of layout fragments and people subscribed to them that have made changes. If you export, change and re-import it will break those user's customization.
Susan:
What about seeing the wrong portlet in place of another?
Eric:
This is a runtime uPortal bug, not in the import or export code.
Drew:
This is a maintenance issue, not an upgrade issue. It does not affect complete upgrades. With import/export you're supposed to be able to re-import entity files to make changes and manage portal data. The import re-ids nodes on the import. Fixing this may be easy since there is code that strips off the IDs on export, removing that code should be easy on export.
Tim:
Is there another approach that DLM could take where these DLM ID references could be resolved?
Eric:
Not really, DLM needs a way to track which node moved where in a layout and having a unique ID that does not change for each node in a layout.
Susan:
Yale will work on getting the updated layout export code published for 2.x