Is it possible to Index multiple entities within same index using Hibernate Search? I have 3 entities COUNTRY,COMPANY and SECTOR. These entities are not related to each other. A user can search across all these entities similar to a google search. I want all entities indexed in one Lucene directory.
Yes you can. Just use the same index name within the #Indexed annotation:
#Indexed(index="foo")
Related
I want to improve performance by not doing search query where i know that data will be unique.(In my app every new user will require default data. Which will be created in server side where there is no need to do unique test.)
#UniqueConstraint is only used for schema generation. JPA doesn't do any search for unique constraints at runtime.
I want to manage multiple projects data in mongoDB. Each project contains multiple users from multiple departments with multiple role assigned to them. plus certain task is assigned to each user. Now I am confused about schema, not able to decide which entity should be kept as collection & which one as document ? What is the best efficient way to store ?
should I keep all under single collection as embedded documents or in separate collection ?
Thanks
First of all if you are using mongodb you should know why are you using it. MongoDB is not about normalize stuff. If you are able to create data structure is de-normalize way then and only then go for MongoDB.
I think you should maintain one single document containing all the mentioned things above. But the scenario which you have mentioned above is good for relational database. you need only 3 entities in relational database and your problem is solved.
Still if you want to go for mongodb you can go with one collection only. which contains project details number of users working there and their roles and department.
I have one primary key (Integer) on my entities, but I also have a UUID on those entities that I do a lot of searches on. I am wondering if it is possible to make that UUID a key as well, so that Hibernate (or whatever) does not have to fetch the entity from database each time, but can check its cache first instead?
I'm not sure about Hibernate. But if you use EclipseLink in the 2.4 release there is support for cache indexes on non-id fields. Then any query using the UUID will be able to obtain cache hits.
See,
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Indexes
At my company we have a database with one table being so big that it was splitted into 3 tables. They all share an ID and the info is NOT normalized so there is info for several entities in the tables, some entities actually have some fields in one table and some fields in the other tables.
There is a new project and they want to use nHibernate to map it, so that the code uses the ORM and we work on objects rather than query strings.
One of the problems we are having is that we are using nHibernates fluent "join" to map the 3 tables into one, but nHibernate won't let you map components inside joins, also it seems liek you cant map components that are split several tables.
Is Entity Framework 4 capable of doing this?
Yes. So does EF 1. It's called entity splitting.
I've never came across an app/class like Zend Search Lucene before, as I've always queried my database.
Zend_Search_Lucene operates with
documents as atomic objects for
indexing. A document is divided into
named fields, and fields have content
that can be searched.
A document is represented by the
Zend_Search_Lucene_Document class, and
this objects of this class contain
instances of Zend_Search_Lucene_Field
that represent the fields on the
document.
It is important to note that any
information can be added to the index.
Application-specific information or
metadata can be stored in the document
fields, and later retrieved with the
document during search.
So this is basically saying that I can apply this to anything including databases, the key thing here is making indexes for searching.
What I'm trying to grasp is where exactly should I store the indexes in my application, let's take for example we have phones stored in a database, a manufacturers, models - how should I categorize the indexes?
If I'm making indexes of users with say, addresses I obviously wouldn't want them to be publically viewable, I'm just confused on how it all works out together, if there are known disadvantages, any gotchas I should know while using it.
A Lucene index is stored outside the database. I'd store it in a "data" directory as a sister to your controllers, models, and views. But you can store it anywhere; you just need to specify the path when you open the index for querying.
It's basically a redundant copy of the documents stored in your database, and you have to keep them in sync yourself. That's one of the disadvantages: you have to write code to populate the Lucene index based on results of a query against your database. As you add data to the database, you have to update your Lucene index as well.
An advantage of using an external full-text index solution is that you can reduce the workload on your RDBMS. To find a document, you execute a search using the Lucene API. The result should include a field containing the primary key value (as part of the document but no need to make it analyzed for FT search). You get this field back when you do a Lucene search, so you can look up the respective row in the database.
Does that help answer your question?
I gave a presentation recently for MySQL University comparing full-text search solutions:
http://forge.mysql.com/wiki/Practical_Full-Text_Search_in_MySQL
I also publish my slides at http://www.SlideShare.net/billkarwin.