2014/2/10 Davide D'Alto <daltodavide(a)gmail.com>
I can work on this today and start to plan the release for
Wednesday.
Hum, tbh. I'm not sure whether I'll be done with the doc updates by
Wednesday.
There is also OGM-392 (support for optimistic locking in CouchDB) which I'd
love to squeeze in as the current solution encourages non-canonical usage
of CouchDB (we don't take advantage of the built-in "_rev" property).
I don't think this change should block the next release though.
It would also be nice to include this:
https://github.com/hibernate/hibernate-ogm/pull/282
so that people can actually use the enitty manager to create queries
+1
On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling <gunnar(a)hibernate.org>wrote:
> Hi,
>
> One thing I'd like to address before doing the next OGM release is the
> structure of public packages in the datastore-specific modules.
>
> Currently we have the following structure:
>
> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
> ...
>
> I think it makes sense to pull the datastore-specific package up one
> level,
> moving all the types of a backend under one shared super-package. So it
> would like this instead:
>
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
> ...
>
> The reason I'm bringing this up is that we're introducing new user-exposed
> types with that release: the store identifier types (MongoDB, CouchDB
> etc.)
> and their properties class (MongoDBProperties, CouchDBProperties etc.). So
> if we agree to do this change it would be good to do it now before having
> to move these public types later on.
>
> Another question is how to differentiate between public and internal
> packages, but I think we can discuss this later on, as a change would only
> affect internal packages. Emmanuel and I couldn't agree on a best approach
> when discussing it shortly, so this might need some more time :)
>
> Any thoughts?
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>