JPA : TCK request and JPA2.1

It is now almost exactly a year since we submitted a request for access to the JPA2 TCK (JSR0317). We provided everything requested of us by Oracle, and we still haven't received the JPA2 TCK. Just to say Happy Anniversary Oracle on this evidently controversial request. The only possible reasons that I can think of for lack of provision of this are either incompetence, or deliberate prevention of access. Needless to say, we no longer wish to have access to this TCK.


On a related note I was asked whether I'd be participating in the JPA2.1 (JSR0338) expert group. I did think about it, no really! :-) But then I remembered that I spent many hours sending emails chasing Oracle employees to fulfil the request for the JPA2.0 TCK all to no avail. We also have to remember that JPA was born out of politics nothing more. Consequently the answer had to be a NO.

I have every willingness to participate in truly open standards on Java persistence, based on technical reasons. Any such participation would be with open mailing-lists/forums, and an open testing capability so that anyone can validate the compliance of any implementation. JPA, and the JCP process it operates under, is not that; JPA standardises things like "Criteria" that is widely recognised as inelegant (many call it ugly actually) and hard to use. A standard should take something that has become accepted as a good way of doing something (such as QueryDSL, for example) and convert it into something coherent with a clean API (like what we did with JDO Typesafe); it should not invent something and impose it on people. The JPA philosophy is simply wrong in this respect. I wish them good luck with JPA2.1, and DataNucleus will, at some point (typically as soon as the spec is made public), implement what they come up with, but I will not be party to its "design".

DataNucleus v3 and HBase

DataNucleus AccessPlatform v3 provides an opportunity to bring some of our other datastore plugins closer to the standard of the more mature long-supported datastores (e.g RDBMS). In the case of HBase, the plugin provided with v2.0 offered basic persistence and querying, at best. In v3 this is already much improved.

1. You can now run SchemaTool against HBase. This operates in either "create" or "delete" modes, and allows you to manage the schema required by your persistable classes.
2. When a relationship was persisted with v2.0 it simply serialised the related object. This broke JDO/JPA cascade rules. In v3 the column for the relation in the owner stores the identity (or identities when persisting multi-value relations). This also provides correct cascading of persist and update.
3. When a String field was persisted in v2.0 it was Java serialised, meaning that it was not readable with something like "hbase shell". In v3.0 String/char fields are persisted as the bytes of the field value, hence readable.
4. With v2.0 we provided value generation using "uuid", "uuid-hex", etc simple generators, but not accessible by default. In v3.0 the default (JDO "native", JPA "auto") is "uuid-hex", and we also provide an "increment" generator (contrib from Peter Rainer).
5. In v2.0 we only supported "application identity". In v3.0 we also support "datastore identity" (surrogate identity column).
6. In v2.0 we didn't support storing a version against the object. In v3.0 we do allow this.
7. You can now embed persistable fields into the table of the owning object, and also nested embedded fields.
8. Now supports HBase 0.90
   

Obviously there is still much more that can be done - see the datastore features comparison table. One that will give more performance is to handle more of any query filter in the datastore, rather than just processing all in-memory. Contributions for this and other things are very welcome. But then we aren't even at 3.0 Milestone 1 yet ...