Talk:EclipseLink/DesignDocs/Extensibility

• Tom, Chris,
• Started thinking about details on your analysis doc, here are some thoughts I am starting to have on the following before the meeting.
• http://wiki.eclipse.org/EclipseLink/DesignDocs/Extensibility

• - management component for schema changes sounds interesting - will this have a design-time (dali like) and runtime component (jconsole/jrmc/em like). How will we tie this interface in with future proposed changes to our existing mgmt/performance interface - which requires a lot of work to add for example diagnostics.
• - dynamic redeploy - should we be part of a possible future JEE7 standard
• - is this pure EE or SE (if we extend JPA then it is no longer only SE)
• - SDO is already schema dynamic (without persistence without dynamic JPA) - maybe we can reverse leverage part of this
• - can we keep a change summary of the schema and only fix it when we serialize to DB
• - design: i think we need to move from hardcoded column names to the ms map strategy where we dynamically define all colums (with no limit on the number) - how do we deal with join tables? This is your name/value pair "value rows" alternative in your doc.
• - In the "value rows" design or "Attributes as a Map" - i think of the metadata about metadata as a 2nd level of persistence. I see functionality where we can track changes to the dynamic schema and expose operations like undo, diffs and history tracking.
• - How would we handle reading in/regenerating new versions of a schema directly from the database? just in case the DBA dept maintains control over the dynamic schema
• - Addition to above: how can we allow a web services end point control over the dynamic schema - we may want to extend the extensibility interface to multiple areas of control
• - Runtime: Where to demarcate where changes to the schema can occur - we will at least need to finish all existing transactions before allowing the schema change to occur
• - Security: From reading the Microsoft document - it looks like the #1 or #2 requirement is security - in all 3 of (user, schema-modifier and even original designer). How can we verify to the client that even developers do not have access to their data - this may already be a part of the DB layer.

• minor:
• Sp: "They with to add"
• Sp: "the user calls uses"
• Sp: "Filed-based-extension"
• "A table structure like time one in the Value Rows Schema " - broken "Value Rows" link
• "For Persistent Extensions above" - broken "Persistent Extensions" link

20110117: added to talk page as requested