[
https://issues.apache.org/jira/browse/JDO-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937931#comment-13937931
]
Michael Bouschen commented on JDO-651:
--------------------------------------
Interesting idea!
Questions:
With tx.commit being a no-op, how do the changes get synchronized to the
datastore? On each change of the Java instance? Does the user need to call
flush? Or is flush a no-op, too?
When supporting persistent-clean ->hollow on commit, how about doing a
persistent-dirty -> hollow on rollback?
> Modify specification to address NoSQL datastores
> ------------------------------------------------
>
> Key: JDO-651
> URL: https://issues.apache.org/jira/browse/JDO-651
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
> Affects Versions: JDO 3 (3.0)
> Reporter: Matthew T. Adams
> Assignee: Matthew T. Adams
> Labels: jdo, nosql, profile, specification
> Fix For: JDO 3 maintenance release 2 (3.2)
>
>
> There is increasing interest in NoSQL datastores (Google BigTable, Apache
> HBase, VMWare Redis, etc), which not only do not support SQL, but also do not
> necessarily provide support for traditional consistency or queriability
> features or guarantees, instead offering features like eventual consistency,
> key-value storage mechanisms, etc.
> This request is to modify the JDO specification (and TCK & RI) so that it
> relaxes certain portions of the specification, perhaps in the form of
> profiles similar to JavaEE 6 profiles, to allow datastores that may not
> support queries in general, do not support the ACID requirements, or that
> support key-value-based storage mechanisms to be JDO-compliant. Additions to
> the specification may also be needed in order to directly address NoSQL-type
> datastores, in a manner similar to its treatment of relational persistence
> mechanisms.
> Additionally, this request would serve to better support persistence on micro
> platforms where consistency, queriability, etc, may not be supported.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
