Hello,
As a general rule, we release when it's ready and don't give out specific dates :)
Instead of giving you a meaningless date or even worse a meaningless release marked as "Final", let me share our roadmap. We would like these in before we mark it as 4.0 Final.
Quote:
# Hibernate OGM 4.0 Beta5
## Annotation based option system
Each datastore can use specific annotations to customize its behavior. The user can use either annotations or a programmatic API
- offer ability for each dialect to react to metadata specific information
- programmatic and annotation based
- for different scopes: generic, type and properties
- retrofit this for MongoDB’s options
## CRUD support for CouchDB
Support the CouchDB document DB to read and store entities and associations.
# Hibernate OGM 4.0
## Performance and stabilization
Review performance and overall choices before going final.
## Improved Neo4J navigation
Support Neo4J with ability to keep node reference for cheap navigation when resolving proxies thus avoiding unnecessary lookups.
- Store tuple as data snapshot via IdentityMap or enhanced entity
- Use stored tuples as navigation tools instead of fetching (graph databases)
## Batch changes per transactions
Offer the GridDialect the option to receive a batch of operations to execute. Some drivers are better that way and can increase the isolation lever.
## Additional query support
### Query support for Neo4J
Support JP-QL and native queries.
### Query support for CouchDB
Support JP-QL and native queries.
### Clean query parser design
Fix how the field bridge is selected for a given property.
- Automatic approach
- Manual overriding option (convention based, annotation or SPI?)
Use Hibernate ORM metadata (EntityPersister) to find the type of a property for HQL literal conversion)
- extract this logic and reuse it for all backends
### Move to proper OgmLoader implementations
Discuss how to properly load objects via the OgmLoader approach.
### Cache query plans
Look at Hibernate ORM’s HQLQueryPlan which essentially caches results of a query translator which in term calls the entity loader. A similar design or even interface result is probably possible
In particular, we know we need to improve performance for queries and have strong suspects.
If you use OGM as CRUD for MongoDb, this code has been stable for quite some time and I would not worry.
Note that the road map is public but hosted on the soon to be released new website and we did not take the energy to update the old instrastructure. Stay tuned.