Compass 1.2, providing search capabilities for object models, released

Home

News: Compass 1.2, providing search capabilities for object models, released

  1. Compass, a Java Search Engine Framework, has released version 1.2. Compass simplifies the integration of search functionality into any Java application. It is built on top of the excellent Lucene library and adds several features on top of it (most notably, transactional support, including long running transactions). Compass allows to map your domain model (Object, pure XML, and the map like Compass Resource) into the search engine simply using either xml or annotations, and integrates with leading ORM libraries (Hibernate, TopLink, OpenJPA) and web frameworks (Spring MVC, Grails) in order to simplify even more the introduction of search into an application. A nice write-up on why Compass or Search make sense can be found here and the birth of Compass is still valid on how it came to be. Does search functionality is a must have in an application? Do you agree that search feature can be much more than just a "google like" search box in your website and actually change the way people interact with applications (ala Google Desktop or Mac Quicksilver)?
  2. So how does this stack up to Hibernate Search ?
  3. Hibernate Search is an unbelievably complicated architecture for clustered J2EE applications. I dont know what is the idea of having shared/locked directory and JMS, when all you need is jdbc datastore for lucene with write-behind which can take care of transaction, backup, clustering etc. It looks like compass has jdbc store. but it does not clarify if that solves the clustering problem. anybody knows?
  4. It looks like compass has jdbc store. but it does not clarify if that solves the clustering problem. anybody knows?
    I'm also interested in this. Also, do you know if there are any other commonly available (hopefully standalone) JDBC store / 'Directory' implementations for lucene? It should not be rocket science to make one. I'v clustered Lucene using it's RAMDirectory with Terracotta, but would like to give a JDBC based aproach a try. /Henri Karapuu
  5. Lucene Jdbc Directory: An implementation of Lucene Directory to store the index within a database (using Jdbc). It is separated from Compass code base and can be used with pure Lucene applications.
    Looks like this itself is standalone.
  6. Hibernate Search is an unbelievably complicated architecture for clustered J2EE applications. I dont know what is the idea of having shared/locked directory and JMS, when all you need is jdbc datastore for lucene with write-behind which can take care of transaction, backup, clustering etc.

    It looks like compass has jdbc store. but it does not clarify if that solves the clustering problem. anybody knows?
    When you have your "jdbc datastore for lucene with write-behind which can take care of transaction, backup, clustering" that scales out as much as the proposed clustering architecture for Hibernate Search, let me know :) And if, you make it work, then just write a one class DirectoryProvider for Hibernate Search to wrap that up. Just like Compass, Hibernate Search are not tied to one architecture whether clustered or not. Back to the main topic, congrats to Shay :)
  7. Emmanuel, 1)If the indexes are stored as tuples (unlike file system which gets locked completely) i do not see any reason why it can't scale. 2)If you are justifying JMS architecture for scaling for search indexing (which could be less than 10% of persistence need in an app), why are we not doing that for all persistence needs (including hibernate)? 3)For all this complexity, basic transactional integrity is not guaranteed. While hibernate search talks about transaction, if the transaction fails, integrity goes for a toss (with lucence lock exception) and indexing for subsequent users/threads fail. 4)By reading the document i felt shared dir & JMS were the only 2 architectures possible for clustering, which i understand now is not true. If so, pls update the document. BTW, I made the comment for comparison and not to pull down hibernate search. And the fact remains that Compass came with lucene jdbc implementation which could enable a much simpler and better architecture. mani
  8. Emmanuel,
    1)If the indexes are stored as tuples (unlike file system which gets locked completely) i do not see any reason why it can't scale.
    2)If you are justifying JMS architecture for scaling for search indexing (which could be less than 10% of persistence need in an app), why are we not doing that for all persistence needs (including hibernate)?
    3)For all this complexity, basic transactional integrity is not guaranteed. While hibernate search talks about transaction, if the transaction fails, integrity goes for a toss (with lucence lock exception) and indexing for subsequent users/threads fail.
    4)By reading the document i felt shared dir & JMS were the only 2 architectures possible for clustering, which i understand now is not true. If so, pls update the document.

    BTW, I made the comment for comparison and not to pull down hibernate search. And the fact remains that Compass came with lucene jdbc implementation which could enable a much simpler and better architecture.

    mani
    Maybe performance (speed) figures for a filesystem based vs. jdbc based Lucene Directory are different. Jdbc-based solution promote the "embedding" of fulltext engine in the using app and increased load on your DBMS since, I think, Lucene Directory tables should be in the same DB of your data, otherwise you should go into true 2PC. When the above become issues, the solution is to think at the full-text service as an independent service with its own balancing architecture. The web app would use any high performance IPC (ICE, primarily, or IIOP) for RPC. Obviously, a wise use of interfaces would allow for total transparency of the underlying implementation. Guido
  9. Emmanuel,
    1)If the indexes are stored as tuples (unlike file system which gets locked completely) i do not see any reason why it can't scale.
    2)If you are justifying JMS architecture for scaling for search indexing (which could be less than 10% of persistence need in an app), why are we not doing that for all persistence needs (including hibernate)?
    3)For all this complexity, basic transactional integrity is not guaranteed. While hibernate search talks about transaction, if the transaction fails, integrity goes for a toss (with lucence lock exception) and indexing for subsequent users/threads fail.
    4)By reading the document i felt shared dir & JMS were the only 2 architectures possible for clustering, which i understand now is not true. If so, pls update the document.

    BTW, I made the comment for comparison and not to pull down hibernate search. And the fact remains that Compass came with lucene jdbc implementation which could enable a much simpler and better architecture.

    mani
    Mani, I have my reasons for going the way Hibernate Search has been designed and to partly disagree with your statements. I don't think this forum post is the appropriate medium to talk about it, but feel free to start a thread in the Hibernate Search forum and I will be more than happy to have this discussion with you, it should be interesting and I think I will convince you :). And as I said, if the JDBCDirectory is what you want, you just need to write a one class provider to Hibernate Search: Sylvain has done that reusing the Compass JDBCDirecotry implementation.
  10. maven repository release[ Go to top ]

    A release into the maven repository would be nice and lower the barrier, against atleast me trying it, a bit.
  11. Re: maven repository release[ Go to top ]

    +1 Nice project but it would be good to be able to get something up and running quickly with maven.
  12. What abt Mapping and configuration xml files of compass 1.0? :) Is it easy now?
  13. Compass is amazing[ Go to top ]

    Hi, Congrats to the Compass team ! "Full text", Google-like search on Objects is really amazing. I'm a huge fan of the approach in general, and definitly agree with the foundations you describe in the referenced blog post (which I had not read before). A small "search" input field is definitly easier and more comprehensive than bloated forms with dozens of widgets... Even for "advanced searches", the Compass syntax makes retrieving objects simple, and accurate. On the technical side, so far Compass has met ALL of my expectations, and even more. Integrating it with other popular technologies like Hibernate and Spring is a no brainer, and so is the mapping using annotations : enabling search on Domain POJOs is a matter of minutes ! Then, for more advanced use cases, the analyzers and query API allows fantastic stuff I would not even have dreamt of with xxxQL... To me, this "feature" is one of the most interesting stuff in OOP land currently. It opens really cool perspectives for building better applications. Thanks to the team, and keep up the good work ! Cheers Remi PS : agreed with the other poster for the maven repo release... This would definitly be nice !