Is it possible to use hibernate-search only for it's annotations (bean => document/document => bean mapping), without using a database at all? If so, are there any online samples that show basically how to set this up?
I found the following: http://mojodna.net/2006/10/02/searchable-annotation-driven-indexing-and-searching-with-lucene.html, but I'd prefer hibernate-search if it supports my use case.
Hibernate search 3.4 has decoupled the query engine from Hibernate Core. For instance, Hibernate Search is reused to implement queries with Infinispan. I don't know if the code is packaged so that you could use HS with, let's say Spring and JDBCTemplate (something I would like to do). That's a lead I will investigate later but maybe you can check it out...
Starman is correct, Hibernate Search in version 3.4 is abstracting the search engine from Hibernate Core, and the Infinispan Query is an integration example which works fine without a database. There would be no problems with Spring either, but you'd need to make sure to send update event to the query engine so that the index doesn't get out of synch. When using Hibernate the advantage is that it transparently listens for changes to the database and applies them to the index at transaction commit, so the index is always in synch (or close, if configuring Search to use async backends).
I'd suggest to look into the code of Infinispan Query, as it's very small and just delegating calls to expose an Infinispan flavoured API. Most of the code is tests or integration to properly manage the lifecycle of the engine: start and stop it together with Infinispan.
I don't think that's possible because when you enable Hibernate search you are enabling that on a Entity and that Entity has references to the table and the search index.
Related
I am starting with a new project and currently evaluating whether to use JPA or JDBC. Our operations mostly are going to be an bulk-insert and bulk-read and very rarely single insert/read.
I checked a prototype with JPA and JDBC and realized that both has its own merits and limitations.
Considering the current use case that for a fact I will only have always a bulk read and bulk write, which one will be a better option to go with ?
Spring JPA Repository gives a simple method save(Collection) which can take a collection and save as well.
Also Validations are also not be considered here, as the payload will already be validated in the layers above and the database layer should just do the read/write operations.
Does the JPA save(Collection<>) method in turn uses the jdbc templates or is it entirely a different implementation ?
Thanks in advance !
We use both JPA and JDBC in one application wiht no problem. Preferably we use JPA/JPQL and fall back to JDBC if needed. For JPA we use Spring Data JPA and for JDBC Spring JDBC Template.
there exists a requirement which sounds quite simple: support a couple of RDBMS (which i intend to do by using JPA) and MongoDB (spring-data-mongodb is preferred) for persistence. More precisely either the one or the other has to be configured and used, i'm not talking about a cross store.
The procedure shall be the following: code the application, deliver the .war to the customer, in a config file the customer puts the persistence information like the databaseurl (i.e. either mongodb:localhost/test or jdbc:oracle:thin:1521#foo).
Additionally it would be nice to extend the implemenation for further datastores like couchdb.
Is there a best practice or at least any of a non-too-much-overhead-solution which is not that dirty?
Is Eclipselink an option? The latest supports JPA for both RDBMS and NOSQL (including Mongo)
https://blogs.oracle.com/theaquarium/entry/jpa_and_nosql_using_eclipselink
I am currently developing a project with similar needs. I can advise you according to my experience.
I believe that the major concern here is not regarding the technology but more regarding how you will structure data. For that I advise you to use the AbstractFactory and FactoryMethod design patterns. Regaring technology I am using Morphia for MongoDB and JPA for MySQL (as an example) and it's working like a charm.
So the easiest way is to create interfaces for all the objects you want to persist, and then do an implementation for MongoDB with Morphia tags and another with JPA tags. Create one factory for MongoDB that will deal with all the CRUD operations in the MongoDB objects and do the same with a JPA factory.
When the application is starting, you only have to verify the user choice for persistence and then initialize the corresponding factory.
DataNucleus JPA allows you to persist to RDBMS, MongoDB and a host of other datastores (LDAP, HBase, AppEngine, Neo4j, etc), with a simple change to the connection URL, and has done so for quite some time
I am trying to configure hibernate search for my application by reading several web tutorials, the majority uses annotation but I uses xml mapping, also, many tutorial are saying to use spring and maven while I don't uses these.
Can someone help and provide some starting point for configuring hibernate search, many web tutorial are not working for me
The application is a gwt application using gilead with hibernate on the back end
As pointed out in the previous answer, Hibernate Search does not have a xml configuration. You can configure Hibernate via xml, but not Search. Since Hibernate Search 3.3 there is an alternative, however, which is the programmatic configuration api - http://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#hsearch-mapping-programmaticapi
There is an object called SearchMapping. Once instantiated it offers an fluent API to configure Search the same way you would do with annotations. Add the configured SearchMapping instance to your Hibernate Configuration instance using the key *hibernate.search.model_mapping* and Search will automatically bootstrap together with Hibernate Core. There is not much to it. You don't need Spring.
Once Search is running you probably want to write a few lines of code to index your existing database. There is code for that in the online manual.
Last, but not least you need some searches. Have a look how to create a FulltextQuery. Your system probably gets some sort of search input in what for so ever. Your task is to transform the search input from the "frontend" into a Lucene query which you can then pass to Search in order to execute the search and return managed objects.
Last, but not least - maven is a completely different thing. Now we are talking build systems. Using maven you can get automatically download the artifacts from the JBoss Maven repository. However, there are also dist bundles on SourceForge is this is more what you are after. Check http://www.hibernate.org/subprojects/search/download for Search download information.
Hope this helps.
http://docs.jboss.org/hibernate/search/3.3/reference/en-US/html_single/#d0e43
Hibernate Search, however, has itself its own set of annotations (#Indexed, #DocumentId, #Field,...) for which there exists so far no alternative configuration.
I also remember seeing something like this in "Hibernate Search in Action", where the author said that there's not much demand for non-annotation configuration (I don't have my copy now, so, I may be wrong). I guess that there is still not enough demand.
Note that Hibernate itself can be configured via XML, and I assume that you can mix both (XML for Hibernate mappings, annotations for Hibernate Search mappings).
Hey I am developing an desktop application using Spring and Hibernate, and I have a problem with lazy initiation. I looked in the web and every solution is related to the open session in view pattern, but I can't use this pattern. I've also tried to get the sessionfactory from the HibernateTemplate, but it returns to me a disconnected session.
Does anyone know other solution?
I would suggest that you basically have two solutions:
Make arrangements to keep a Hibernate session open when you access a lazy-initialized object or collection. That means you're going to have to carefully mark your transaction boundaries in your code, a la the "open session in view" pattern. Spring makes this possible, but in a desktop application it won't be as straightforward as a web application where the transaction boundaries are a little more obvious.
Turn off all the lazy-initialization for your persisted objects in Hibernate.
Option 2 could lead to a lot of unnecessary database access, and option 1 means you have to seriously study your workflow and use cases.
Hope that helps!
One option is to call Hibernate.initialize() on the entities or collections to force initialize them. You'd want to do this before you return the data back to your view. I would consider this carefully, since it's going to generate a lot of SQL statements back to the database.
You may want to look into using "fetch" in your HQL queries or configuration the fetch mode to "eager" in your mappings (I believe it's FetchMode.EAGER in JPA or lazy="false" in hbm.xml).
#Jose: Don't manage the Session in your own ThreadLocal. Use SessionFactory.getCurrentSession() and configure Hibernate to use the "thread" SessionContext.
I had a very similar problem, and as I was not able to find any really appropriate solution to it. I came up with my own one combining a lot of different approaches found on the web and posted them to my blog.
Sorry, that I don't put it in all here, but it is to much work to do it over and over again in all the forums I found people having this or a similar problem
Remote Lazy Loading with Hibernate and Spring
I'm researching the development of Enterprise Applications in Java, .NET and Groovy. For each platform, we're going to try how hard it is to realize a simple SOAP web service. We'll use the tools and libraries that are most commonly used, to research the real world as accurately as possible.
In this regard, when using Hibernate for persistence, would it better reflect the real world to use the new JPA (Java Persistence API), or the Hibernate custom API that existed before JPA came around?
As you're probably already aware, as of 3.2 Hibernate is JPA certified. You can easily use Hibernate as your JPA provider without having to use any of Hibernate's "custom" APIs.
I'd recommend using straight JPA with Hibernate as the provider. And use annotations rather than XML (much nicer).
Then when you need a little something extra you can always get the Hibernate Session. For example I often find I need to do this in order to pass a collection to a query as a parameter (setParameterList).
It's funny how you worded your question
new JPA ... or plain old Hibernate
Sounds like one has been around forever and the other has just been released. Of course it's not true. JPA was influenced not just by Hibernate but also by TopLink and by J2EE entity beans. The first reference to JSR 220 draft is back from 2003 - how is that for new?
If you use JPA with Hibernate you still use Hibernate and is free to apply any proprietary extensions Hibernate has.
So the choice is yours: use proprietary API or use equivalent established and standard API...
You could stick with a pure JPA spec, just in case you want to swap out Hibernate, but what you'll probably find at some point is that you're never going to swap it out, and you've been missing out on all the really great Hibernate-specific features.
I'd recommend using Hibernate directly, and as Damo suggests, annotations instead of XML. Make sure you have a firm understanding of the "magic" that Hibernate brings. If you're not careful, you could really thrash the database. For example, there's an n+1 query problem depending on how you do #OneToOne joins:
Hibernate OneToOne automatic join fetching (resolving n+1 problem)
I'd also recommend to use an embedded database for unit/integration tests on your Hibernate queries, and watch the SQL that's generated to make sure it looks like something you'd write by hand.