DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Type: Improvement Improvement
Status: Closed Closed
Resolution: Won't Fix
Priority: Minor Minor
Assignee: Unassigned
Reporter: Erik Bengtson
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
DataNucleus AccessPlatform

Metadata and Queries should use a Type not bound to java Class type It should allow Types from any language, such as XML

Created: 19/Oct/09 04:25 PM   Updated: 19/May/12 04:21 PM   Resolved: 12/Jan/12 05:19 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Issue Links:

 Description  « Hide
To be able to support any language in queries and persistence. The goal is to be able to handle types of any language without the need to convert the Type into Java Class type.

This should allow navigating/modifying/querying Types and its properties without converting to java objects (entities)

Sort Order: Ascending order - Click to sort in descending order
Erik Bengtson added a comment - 27/Nov/09 09:47 PM
StoreManager should not rely on StateManager/ObjectManager, and use IOC pattern, so we provide a common store and query engine for any API/any language.

API -> API impl -> API Manager -> StoreManager
API -> API impl -> Object Provider(field manager, field provider) -> Persistence Handler
API -> API impl -> Object Provider(field manager, field provider) -> Query

Erik Bengtson added a comment - 27/Nov/09 09:48 PM
The StateManager thing should be only be accessible in the JDO impl and JPA impl

Erik Bengtson added a comment - 27/Nov/09 10:34 PM

API -> API impl -> Object Manager -> API Manager -> StoreManager

Andy Jefferson added a comment - 06/Jan/10 02:50 PM
Comments from email (erik)

The goals are:

- Support other APIs than JDO/JPA
- Have store.* implementations supporting any API, and regardless the
API the object is persisted.
- Metadata oriented.
- Support any language types, such as XML types, JSON types or java
types (as today)

From the user perspective, it means that he can persist for example
XML entities without needing to create java types corresponding. Types
persisted by the Store are not bound to Java Types anymore.

Example of API in XSL:

<xsl:stylesheet version="1.0"
<xsl:template match="/">

<tns:persist xmlns:tns="http://datanucleus/persistence">
    <xsl:copy-of select="."/>


Example of XML document persisted:

      <v1:person xmlns:v1="http://mysample">

Given that the above document is provided to the XSL, datanucleus
persists it without any need to define java types. The only thing
happening is that the XSL engine calls the Datanucleus functions.

The only thing necessary from the user side is to have a mapping
metadata associated.

<class name="v1:person" xmlns:v1="http://mysample" table="RDBMS_PERSON_TABLE">

PersistenceHandler2 is a generic inversion of control to persist any
object with given a mapping.

It's very simple, PersistenceHandler2 asks the ObjectProvider based on
the metadata and flags to provide the fields to persist/retrieve.

Of course in runtime whatever object is transformed to a java object
because the JVM is java. For instance, java classes remains as java
objects, xml types are transformed to Node objects. In the end,
PersistenceHandler2 will work with "primitive/simple" types to
persist. Complex types are decomposed by ObjectProvider.

We have the layers:

- API - To handle the user API
- Language/API - To handle types and generic API for a given language
- Store - to handle the persistence


-for java Types: API: JDO, JPA, HTTP Rest (XML, JSON); Datastores:
Many; Components: api.jpa (API), api.jdo (API), rest (API),
objectmanager (language/API) and store.* (Store).
-for xml Types: API: XSL, XQuery, HTTP Rest (XML). Datastores: Many;
Components: api.xsl (API), api.xquery (API), rest (API), XXX
(language/API), store.* (Store).
-for Json Types: API: HTTP Rest (JSON). Datastores: Many; Components:
json (API), store.* (Store).

So, in the end the benefit of using PersistenceHandler2 is that
store.* implementations will support any API/language types because
it's not bound to java types.

The Query engine will also need a few modifications, but it's very little.

I'm migrating store.ldap to PersistenceHandler2, but I still have to
solve the design for embedded types. You can expect changes in the
PersistenceHandler2 api.

If you see store.hbase it's already migrated. it's totally free of
JDO/JPA apis. It's not yet free of java types, but this will come by
replacing Class by

Andy Jefferson added a comment - 18/May/10 08:27 PM
Presumably the point here is that this was to be done in 2.1 timescales ? yet we are very close to a 2.1 release. I don't see why we should have to go through yet another API refactor going 2.1 -> 2.2.

Andy Jefferson added a comment - 22/Feb/11 06:11 PM
My previous comment above applies equally now in the 3.0 release cycle. Once 3.0 is "Release" then the API changes have to stop, so I would strongly suggest that if you want this, then it is implemented asap.

Andy Jefferson added a comment - 12/Jan/12 05:19 PM
No resource for such things. Obviously if somebody comes along who is willing to provide their time then great