Skip to main content

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.

Jump to: navigation, search

Talk:EclipseLink/DesignDocs/Extensibility

20110117 - Michael O'Brien:

  • - 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.
--Tom.ware.oracle.com 15:40, 17 January 2011 (UTC)
  • - dynamic redeploy - should we be part of a possible future JEE7 standard
I do not think our implementation will cause a "dynamic redeploy". Rather, we will likely set some rules for how you get an EntityManager that contains the new mappings. (maybe it'll be the next EntityManager you get, maybe you'll have to get it through a new EntityManagerFactory.) We'll have to discuss this as we progress.
--Tom.ware.oracle.com 15:40, 17 January 2011 (UTC)
  • - is this pure EE or SE (if we extend JPA then it is no longer only SE)
This is EclipseLink functionality (non-spec). We will do our best to use spec-like constructs like persistence.xml, and orm.xml in our design.
--Tom.ware.oracle.com 15:52, 17 January 2011 (UTC)
  • - SDO is already schema dynamic (without persistence without dynamic JPA) - maybe we can reverse leverage part of this
Agree
--Tom.ware.oracle.com 15:52, 17 January 2011 (UTC)
  • - can we keep a change summary of the schema and only fix it when we serialize to DB
We'll have to decide about this later in the design, but I think that schema changes and data updates are likely to occur in separate transactions.
--Tom.ware.oracle.com 15:52, 17 January 2011 (UTC)
  • - 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.
The first iteration will only include basic mappings. In future iterations we may want to allow foreign keys to be stored and I believe this could be done in our "value rows" strategy. At the moment, the plan is to allow a hybrid of map based storage and traditional FIELD/PROPERTY mapping.
--Tom.ware.oracle.com 15:52, 17 January 2011 (UTC)
  • - 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.
Something to keep in mind as we progress
--Tom.ware.oracle.com 15:52, 17 January 2011 (UTC)
  • - 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
There is a metadata API in JDBC. We would use that and potential Platform-based support for databases that have their own improved API. Any user who wants an application of this type will have to come to an agreement with their DBA about allowing schema changes.
--Tom.ware.oracle.com 15:52, 17 January 2011 (UTC)
  • - 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
Not sure what you mean here.
--Tom.ware.oracle.com 15:52, 17 January 2011 (UTC)
  • - 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
We'll have to figure this out when we design that particular feature. We will certainly have to define some rules like that.
--Tom.ware.oracle.com 15:52, 17 January 2011 (UTC)
  • - Security: 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.
In the end, we provide a framework that allows users to take advantage of the the database provides. Our extensibility features will have to be used in conjuction with other features like our support for Oracle VPD to allow the user to design their security model. In future iterations we may examine some specific security related extensions for extensible applications.
--Tom.ware.oracle.com 15:53, 17 January 2011 (UTC)

Back to the top