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 ;)

Compass 2.0.0 M3 version includes a really nice feature which is called searchable cascading. Compass support the ability to cascade operations when using the component and reference mappings. What Compass users wanted was the ability to defined cascade definitions for properties that do not necessarily have a component/reference mappings.

This feature is really handy when integrating with an ORM, which, because of a result of Account, the User object will be reindexed. More information can be found in the OSEM docs.

Compass version 2.0.0 M3 has just been released. This release includes several major features, among them are: boosting with all property, spell check support as well as many bug fixes and improvements. For a complete list, please check the release notes. Enjoy!

It seems like most people prefer that the alias will not be included in the “all” property by default. As of latest 2.0 M3 builds, it is not. Check CMP-580 for more information.

In Compass, currently, the way to create a Resource (usually when using RSEM) is using the CompassSesssion API. Here is a quick code example of how it is done:

1
2
3

Resource resource = session.createResource("alias");
resource.addProperty("id", 1);
session.create(resource);

This is a bit confusing, especially when it comes to resource creation. Some people confuse the createResource method (which instantiates a resource) with the create method which creates it in the search engine index.

This is why, in version 2.0 (its committed on trunk), this has been abstracted to a ResourceFactory, which is accessible through the Compass instance. Here is a revised example that makes use of it:

1
2
3
4
5
6

Resource resource = compass.getResourceFactory().createResource("alias");
resource.addProperty("id", 1);
 
// open session, begin transaction
session.create(resource);
// commit transaction, close session

This breaks backward compatibility at the expense of greater clarity. It is fairly simple to keep the old behavior as well, but it really cleans Compass up not supporting the old method. What do you say? If it really messes your application, just comment or send me an email.

Mathieu posted that he created a really nice Compass server based on a set of libraries he developed and has it working with php. Check it out here.

Just watched the iPhone SDK event. Looks really nice, but the parts where Scott Forstall (VP iPhone) talked about the development experience cranked me silly. Here are some quotes:

We started with Xcode, and then we enhanced it to support the iphone. […] the great thing is that Xcode knows all about the iPhone SDK […] so when you are writing applications, it will code complete to the APIs in the SDK.

Oh my God!. Apple, I am humbled by your radical and amazing approach to IDEs.

Project Management [..] it deals with all your files for you. Your source file, header files, … . It also integrates with your source control management system. So be it subversion, perforce, CVS, it integrates directly […]. You can check files in and out, you can merge files, … .

Mmm, how I wish I had this features in my crappy development environment. Apple sure as hell push the limit.

And there are so many more wonderful tidbits like this. “It integrates with the iPhone documentation”, “has a debugger”. The debugger part is amazing, the way it is presented (hard to put in into words) goes like this: It has a debugger. But [wait for it] it has a great remote debugger. Amazing. The limits that Apple are pushing the development experience.

Apple are doing amazing things. But come on, are you joking?

Myself and Maurice (the mind behind the Grails searchable plugin) are having an interesting discussion if Compass should, by default, include the alias in the all property.

Currently Compass includes the alias in the all property. And in version 2.0, one can configure if it should be excluded globally or on a per class mapping.

So, I am asking you Compass users, what do you think? Should it be included by default or not?

[Update:] Here is a short example of what I describe here:

Lets assume you have the following POJO:

1
2
3
4
5
6

@Searchable(alias = "customer")
public class Customer {
 
   // ... customer properties
 
}

When alias is not excluded from the all property, then a search for customer will return all the customers. If it is excluded, then a search for customer will not return anything (assuming that you don’t have the token customer on any other property).

NewsFire, my favorite RSS reader for Mac is now free.