Jump to: navigation, search


Revision as of 09:18, 7 April 2011 by James.sutherland.oracle.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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
--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)

Metadata Service

I think the key to this feature (or really the only thing required) is a meta-data service. We should support integrating with a meta-data service in our persistence.xml,

i.e. "eclipselink.metadata.service"="org.acme.ACMEMetaDataService"

We would define an interface for the meta-data service,

i.e. getMetaData(String puName, String tenant, String id) - returns XML meta-data addListener(MetaDataListener listener) storeMetaData(String puName, String tenant, String id, String xmlMetadata)

We would call the meta-data service on deploy, and add the xml file to our existing deployment file and any extensions, or customization would be automatically included. The user would be able to add additional mappings to existing flex columns in their database, or new columns that their DBA added. We already support adding mappings to virtual attributes stored in a Map, the existing VIRTUAL access type will automatically do this. I think it hard codes the name of the variable, so we could add an @Extensions annotation to tag the Map variable, and possible add an EXTENSION access type to match it.


<basic name="newProperty" access-type="EXTENSION">
  <converter>..., etc.

This would allow adding any type of mapping in an extension or customizing any exist mapping or property such as the cache size, and would not require any additional work or annotation as we already support xml overrides.

For adding a extension using a values table, the user could either use the existing ElementCollection for this, or we could add support for an Element mapping that is stored in a separate table. A new mapping type is required anyway for values, as we need to support updating and querying the other table.

For adding columns on the fly, I think we should just add an ALTER option to our existing ddl generation support that would add any missing table or columns to a persistence unit when being deployed.

I don't think we should be doing a lot of work on the MetaDataService other than providing the interface and a simple implementation. I think this should be more oriented around integrating with third party meta-data services. We could provide a basic implementation that stores the xml to a file, or to a lob or xml column in the database. It would be up the user's application and meta-data service to provide a UI to edit the meta-data.

James.sutherland.oracle.com 14:18, 7 April 2011 (UTC)