Matt pointed out an integration between Compass and AppFuse. Cool.

Compass 2.0.0 GA has just been released. This is the final release of 2.0 and another milestone in the Compass project. Nothing much changed from RC2, just fixing some bugs as indicated in the release notes. More information regarding 2.0 release can be found in the M1, M2, M3, RC1 and RC2 posts.

Compass version 2.0.0 RC2 has been released. The release include minor bug fixes and improved support for polymorphic operations both in the API and the query string level. Check out the release notes for more information.

Ohh, and one last thing for all you Maven lovers out there, Compass now has a maven repository at repo.compass-project.org hosting both 1.2.2 and 2.0.0 RC2 versions. Hopefully later on it will get synced with maven central repository.

Compass version 2.0.0 RC1 has just been released. The release includes several major features including: Terracotta integration, Specific Gps indexing, Automatic scanning for mappings, and many many more.

This version will be the final one where major features will get into the 2.0.0 release train. The current plan is to release 2.0.0 RC2 in a week or two, and soon after (a week) release 2.0.0 GA. Both releases will only include bug fixes. This has been a long road, and 2.0.0 has become a really nice release. So please, if you are using old Compass version, take the time to upgrade to 2.0.0 RC1 and give us feedback (make sure you read the upgrade.txt file).

Compass now supports (trunk) automatic scanning of different mappings definitions (a much requested feature). Here is a code example of how it can be used:

1
2
3

Compass compass = new CompassConfiguration().setConnection("test-index")
                 .addScan("com.mycompany", "**/model/**")
                 .buildCompass();

The above code will scan the package com.mycompany and match any sub package that has model in it (ant style pattern matching, can be null). The scanning process will scan for all the typical xml mapping definitions (ends with .cpm.xml), and will try and find classes with @Searchable annotations using either ASM or Javassist (if found in the classpath).

The scanner is supported both in the dtd based configuration and the schema based configuration. Enjoy!.

Compass 1.2.2 maintenance version has just been released fixing major bug when working with a Jdbc directory as well as adding minor features. Check out the release notes for more information.

I am happy to announce that Compass now supports integration with Terracotta. This integration allows for applications that use Compass or pure Lucene to store the index in an optimized, memory based storage, that uses Terracotta as a “network attached memory”.

The latest nightly build supports it. The Artifacts tab allows to download the nightly build as well as view the terracotta integration documentation.

In a nutshell, Compass jar is now a Terracotta Integration Module (TIM), which allows to drop it into the terracotta installation and enable it simply within the application tc-config.xml file. Compass can be configured to store the index in a Terracotta based connection using a one line change in the configuration and easily distribute your Lucene index.

A common question that might be raised (for people who are not familiar with Terracota) is how does a large index will be stored in memory. The answer is that Terracotta takes care of this by fetching and evicting data on demand from the server to the different clients. The TerracottaDirectory (an implementation of Lucene Directory) is built in a way that breaks the file content into one or more byte arrays (their size is configured) which allows Terracotta to easily fetch parts of the file and evict other parts based on certain policies (LRU, LFU, …).

Another question, which is answered in the reference docs, is what will be the Terracotta “root”. When using pure Lucene, the root will need to be defined and configured. When using Compass, the root is already defined (as Compass holds the directories) within the TIM configuration (as well as the locks), and there is no need to configure special Compass terracotta configuration except for listing the Compass module within the application tc-config.xml.

Enjoy!

I asked a while back if Compass should include the alias within the all field or not. Here is the question and the decision was to remove it. After getting some emails and based on some recent forum posts, I am not sure that this is the best “out of the box” experience for Compass users. I am considering turning this back and currently leaning towards it. What do you say? I wish to nail this before 2.0 RC1.

It started with a thread in Compass forum. This turned out to be a new feature request in Compass, allowing for Compass to automatically set the index setting for a property mapping based on the type (if it is not explicitly set). Compass tries to adhere to “Conventions over Configuration” (which I like to name: “COC” :) ), but I guess it can always do better.

For example, most, if not all times, a number (such as int, float, …), should be stored in UN_TOKENIZED form. By default in Compass, if not setting the “index”, everything will be TOKENIZED. Now, with the latest Compass trunk, number types will be TOKENIZED. This also applies to Boolean, URI, URL types.

Last but not least, for numeric types, a specific format has been added named: sortable. This means that if you put it in the format tag for specific mapping definition, it will be stored in an internal sortable format, which makes thing much simpler.

Compass supports the ability to completely index external content (for example, a database mapped using an ORM) using very simple API:

1
2

ComapssGps gps = // ...
gps.index();

This indexing process is a parallel indexing process (by default) based on the number of sub indexes, and will go and fetch all the data mapped using the ORM tool and index it using Compass. The old content of the index (for all types) will be replaced by the new content.

Some Compass users have suggested a (very) valid feature request of being able to just index specific types. So now, this feature is available in trunk (todays nightly will have it). Here is what it looks like:

1
2

ComapssGps gps = // ...
gps.index(Person.class, Account.class);

This will only index the Person class and Account class data (in parallel if possible) and replace only their respective sub indexes. The rest of the index will remain the same.

Now, the only thing left is for the Grails Searchable Plugin to enable it so people will be able to this: Person.index() in groovy.

Finally I can go to bed ;)