30. Oct 2014
23. Oct 2014
01. Oct 2014
22. Sep 2014
07. Sep 2014
28. Aug 2014
08. Aug 2014
31. Jul 2014
28. Jul 2014
23. Jul 2014
17. Jul 2014
10. Jul 2014
06. Jul 2014
26. Jun 2014
19. Jun 2014
Back from holidays, before we resume the work on Hibernate Search 5 for those of you maintaining a mature project we released today a micro bugfix release: 4.4.4.Final
Branch 4.4 is our Hibernate Search line for those using Hibernate 4.2.x aka JPA 2.0. If you're using Hibernate ORM at version higher than 4.3.0 then you want our JPA 2.1 compatible version - as included in WildFly 8.1 : Hibernate Search 4.5.x
For those starting new projects, wishing to help testing, or just interested in all the new power offered by Apache Lucene 4, you should try out our latest development version Hibernate Search 5.0.0.Alpha6
So this version 4.4.4.Final is compatible with the JBoss EAP 6.x line, but remember! If you have a JBoss EAP subscription you have access to the custom built version of Hibernate Search (included for free in the EAP subscription) which entitles you to premium support and more.
If you're using Hibernate Search via this subscription, I would LOVE you could drop me a line, even confidentially if you need so: by giving it away for free we're unable to track its usage and I need some data to justify team expansion options, so this could significantly help improve your free software.
Just one but important fix: a conconcurrency issue which you could hit if you're having high load while performing write operations out of transactions. If you recognize a pattern you might be using, you want to upgrade to avoid missing some index updates.
Special thanks to Yoann Gendre for identifying the problem and providing a test for it!
The Hibernate team is very happy to announce the release of another Beta of Hibernate OGM 4.1!
Progress has been made with respect to query execution and the Neo4j dialect. Also we do provide a so-called
Bill of Materials POM now which the Maven users out there will appreciate (details below).
The GAV coordinates to be used with Maven, Gradle etc. are:
- org.hibernate.ogm:hibernate-ogm-core:4.1.0.Beta6 for the OGM engine and
- org.hibernate.ogm:hibernate-ogm-<%DATASTORE%>:4.1.0.Beta6, depending on the backend you want to use.
Alternatively you can fetch a release bundle containing Hibernate OGM and all its dependencies from SourceForge.
Please note that this new release requires Hibernate ORM 4.3.6.Final or later.
We've reworked major parts of the integration with the query execution machinery from ORM. This enables quite a few improvements in the field of JP-QL as well as native queries.
One is support for polymorphic queries also on those backends which don't use Hibernate Search for querying (Neo4j and MongoDB). This means queries targetting a super-class will return instances of any mapped sub-class as well.
Furthermore, Hibernate OGM now shows the same behavior with respect to auto-flushing you already know from Hibernate ORM. That is, if you submit a query, all pending changes to entities of the effected types will be flushed to the data store in order to ensure queries don't return any stale data. Whereas this works nicely on stores supporting full transaction semantics (namely, Neo4j), some care must be taken on stores with limited or non-existing rollback capabilities. Refer to the reference guide to learn more about the details.
In addition we took measures to cache native queries derived from JP-QL queries. Note that this requires Hibernate ORM 4.3.6.Final or newer. Generally we strive for compatibility with a complete minor release family (4.3.x), but in this case we need to make use of some advanced SPIs only introduced in 4.3.6. The module ZIP we provide for WildFly contains an updated ORM module as well. This will be added along side the existing ORM module, which remains unchanged.
As part of our ongoing work on the Neo4j dialect, associations are mapped to relationships finally the way you'd expect it. There used to be redundant properties on associations which are gone now. Only actual association properties are stored on relationships, e.g. the order of the elements of an ordered list. The following shows an example:
Here we have an entity Father with an ordered collection of Child entities which is mapped by a relationship to each Child node. The birthorder attribute (the name has been given via @OrderColumn) is stored as property on the relationships, just as it naturally makes sense.
On a tangent, we've updated to Neo4j 2.1.3.
Another big usage improvement for Maven users comes in form of our new Bill of Material POM (BOM). This POM defines a set of matching versions of the Hibernate OGM modules and their dependencies, such as Hibernate ORM, Hibernate Search or the different datatstore connectors.
All you need to do is to add this BOM to the dependencyManagement block of your project POM using the special import scope:
<dependencyManagement> <dependencies> <dependency> <groupId>org.hibernate.ogm</groupId> <artifactId>hibernate-ogm-bom</artifactId> <version>4.1.0.Beta6</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
Then you can declare dependencies to Hibernate OGM or any of the related modules without specifying a version, which you will get automatically from the BOM:
<dependencies> <dependency> <groupId>org.hibernate.ogm</groupId> <artifactId>hibernate-ogm-mongodb</artifactId> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-search-orm</artifactId> </dependency> <dependency> <groupId>org.hibernate.javax.persistence</groupId> <artifactId>hibernate-jpa-2.1-api</artifactId> </dependency> ... </dependencies>
To update to a new version of Hibernate OGM, simply update the referenced version of the BOM. This in turn will give you updated versions of any dependencies as required.
As we're approaching the Final release of Hibernate OGM 4.1 soon, your feedback matters more than ever! You can use the following tools to get in touch:
Being nominated is a great honor for us, so kudos to those who brought this on its way! But winning the award would be even better; so go to java.net and vote for Hibernate OGM (upper right corner on the landing page). Every vote counts, and if you ever wanted to give back to Hibernate, this is your chance!
In a word, Hibernate OGM (Object/Grid Mapper) gives you peace of mind when you need to persist Java domain models in NoSQL stores such as MongoDB, Infinispan or Neo4j. Based on the well-known semantics of JPA and re-using many parts of the proven Hibernate ORM engine, it provides simple access to this new world known as NoSQL.
For example consider an existing RDBMS-based application for address management which should be enhanced with some sort of
friendship graph. Now handling and querying graph-like data is not exactly the specialty of RDBMS/SQL. Dedicated graph databases such as Neo4j are much better at this. With the help of Hibernate OGM, you could implement the friendship graph feature using the same persistence API you work with in the rest of the application. But for queries, you’d have the option to resort to powerful native queries written in Neo4j's Cypher language.
Hibernate OGM's vision is to enable applications to leverage those datastores being most beneficial for different use cases. Need deeply-nested hierarchical data? Use MongoDB. Need to distribute your data to hundreds of nodes with awesome performance? Use Infinispan. Need to work with graph-like data structures... You get the picture. But rather than using datastore-specific object mappers or even falling back to a store's native low-level API, you enjoy the comfort and power provided by the Hibernate engine.Really, ORM for NoSQL?!
Now when we talk about this vision, we often get a glance from people which seems to ask
But is JPA/ORM really a good fit for NoSQL?. To be honest, we were asking ourselves the same when starting the project. But over time it became apparent that the general idea of OxM (where x may stand for
graph etc.) is not limited to relational datastores.
Most of JPA’s logical concepts - how do you define entities, their associations and so on - map excellently to NoSQL stores, sometimes arguably even better than to a RDMBS. Just to give an example, @ElementCollection is perfect for mapping nested dependent data in document stores such as MongoDB, which then can be accessed with a simple
get, not requiring any joins; you don’t need to think about fetching strategies, orphan removal and the like.
Hibernate OGM benefits from many features of the Hibernate framework and the eco-system which has evolved around it. Any solution working with Hibernate will work with Hibernate OGM as well without further ado.
You need to validate your data but your store does not support check constraints or similar? No problem, just add Bean Validation constraints to your model and have them automatically validated when persisting your data. Your datastore doesn't provide sufficient query capabilities? Let Hibernate Search help you. It transparently indexes your data via Apache Lucene and allows to execute queries returning managed entities. If you like, even via JP-QL which is transformed into corresponding Lucene queries on the fly.
Of course you choose a certain store because of its specific capabilities, and not all of those may be exposed by a high-level abstraction such as JPA. Hibernate OGM gets out of your way as far as possible and for example allows you to specify queries in the store's native syntax (such as Cypher in the case of Neo4j). Also it's possible to apply store-specific options in a consistent and comfortable manner, via annotations or programmatically. For instance you can configure MongoDB's write concern and read preference settings individually for each of your mapped entities.
So is Hibernate OGM the perfect solution for all the possible challenges you may have when dealing with NoSQL?Of course. NOT.
It will be very useful when dealing with well-defined domain models which need to be persisted, but as always there are situations in which an OxM tool may not be the best choice.
The Hibernate OGM project has come a long way since its beginnings.
All the basics are in place, and at the moment we're fine-tuning some last details for the next release. It will be recommended for general usage and is to be expected soon. We're fixing some remaining glitches in the supported grid dialects and are validating that all the SPI contracts (which you may implement to add support for your favorite NoSQL store) are complete and correct. We’re also have a look on the performance side of things.
In future versions you may expect many more useful functionality such as support for true polyglot persistence (one domain model being spread across several data stores), implicit data migrations upon data load (for schema-less datastores) and declarative de-normalization of your data (ensuring fast retrieval in different use cases).
You like all this? Then don't forget to give your vote for the Duke's Choice Award on java.net to Hibernate OGM. And please spread the word about the project and ask your friends to vote for it, too! If you want to learn more, take a look at our reference documentation. Or check out a complete sample application which has been built for a session at Red Hat Summit earlier this year.
Last week Emmanuel met up with Steven Hawkings and Ramesh Reddy in St. Louis and did a live interview.
They get to put on record the possible correct pronunciation of Teiid and to talk about how Teiid allows you to query across multiple datasources and provide a unified view on data in many different ways.
While the team is busy on significant internal refactoring, we also accumulated 30 minor fixes and improvements which have been merged in the master branch for Hibernate Search 5.
Since it was a while since the last published tag, today we're publishing this 5.0.0.Alpha5 release to make all these minor improvements available already, while the cooler features will need some more work.
This new attribute of the IndexedEmbedded annotation allows you to control if you want to store all ids for related objects which are embedded in the parent's Lucene Document. Very useful to save space in your index, and so improve performance, when you don't need these identifiers.
- As documented in the Migration guide the API to implement a JMS master node was simplified (but changed!).
- A possible loss of index update events was fixed, but not a critical issue as this could happen only if you had a significant load and were not using transactions.
- Better interaction with second level caching.
- Performance fixes: when the DocumentId doesn't match the JPA id we now still execute an optimal database query.
Full details available in the Release notes.
||Showing 6 to 10 of 1221 blog entries||