Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:EclipseLink/DesignDocs/Extensibility"
m (New page: *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/D...) |
|||
| Line 1: | Line 1: | ||
| − | + | *- 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 | |
| − | + | :: I think providing a management component is something we might think about later when we see what users want. They may want to provide their own interface for adding mappings so that it suites the look and feel of their application. | |
| − | + | :::[[User:Tom.ware.oracle.com|Tom.ware.oracle.com]] | |
| − | + | ||
| − | *- 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 | *- 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) | *- is this pure EE or SE (if we extend JPA then it is no longer only SE) | ||
Revision as of 11:38, 17 January 2011
- - 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
- I think providing a management component is something we might think about later when we see what users want. They may want to provide their own interface for adding mappings so that it suites the look and feel of their application.
- - 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