Archive for the ‘Computers’ Category

SOLR, a wrapper for Lucene, was developed by a fellow coworker at CNET. It has recently graduated from the Apache incubation cycle and is now a full fledge project. It not only does it wrap Lucene with a simpler interface it more importantly creates a Restful type of API. I only been using this for a few months now but I love it. It will be launching it into production at work and for my own personal project.

So what is SOLR/Lucene

Lucene is an indexing system, much like a database, except faster and narrower. Narrower? Well essentially an index is a single table with a primary key per entry. It allows extremely fast full text searching with stemming that other databases cannot handle, or even support. MySQL for example, especially MySQL 5 will fall over under heavy load no ifs-ands-or-buts. I’ve seen it happen at work in the lab as well as in production.

Lucene, as well as Solr, are built in Java but Solr needs a servlet container to run like Tomcat, Resin, WebLogic, etc. It runs “next to” your database. All the data in the Lucene index is the same as 1 table in your database. When you write to your DB you will write to Lucene (via SOLR). When you delete, same thing. Updating, yes. You get the point.

Faceting

Solr, and Lucene of course, also support faceting which is very powerful. You have seen this on many sites especially in the world of online shopping comparison. It allows you to see how many other entries also share the same common attributes. In the example of shopping comparison you can see how many other products are also, under 20 dollars, made of cotton, and from Amazon Marketplace. This is very powerful feature and it is perfect for allowing users to drill down through the data.

I will post more findings when I have the time, including configurations.

Wow. This was a lot more complicated than I thought. After several days of research and questions I finally discovered how to make this work. Its all about custom property editors. Please note that many-to-many relationships are not the best thing to use in a production environment. They dont scale well and they are not easy to manage. I later on replaced with Solr, my new favorite implementation.

In this example, many ‘things’ have many ‘tags’ and inversely many ‘tags’ have many ‘things’.

protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) {
   binder.registerCustomEditor(Set.class, “tags”, new CustomCollectionEditor(Set.class) {
     protected Object convertElement(Object element) {
       long id = NumberUtils.parseNumber((String) element, Long.class).longValue();
       Tag tag = tagMgr.getTag(element.toString());

       return new Tag(id, tag.getName);
     }
   });
}

Recently I had to fabricate some nasty rewrite rules involving some unruly query parameters where if one was present do this, whereas if two were present do that, or if none were present redirect somewhere else. I had to step back after a few hours of work to try and look at this problem differently. All of sudden it became clear. Some code is omitted but here are two examples that I am using in production:

RewriteCond %{QUERY_STRING} ^pid=([0-9]+)&pid=([0-9]+)
RewriteRule ^/oldurl.html
   http://%{HTTP_HOST}$1/newurl.html?%{QUERY_STRING} [R=301,L]

RewriteCond %{QUERY_STRING} ^pid=([0-9]+)
RewriteRule ^/oldurl2.html
   http://%{HTTP_HOST}$1/newurl2.html? [R=301,L]

As you can see I am setting up gates or switches. The list went on and on and the order is highly important as you may notice, just as some ‘if’ blocks are (consider refactoring). In the case of a top-down script like mod_rewrite I feel this is not only acceptable but necessary to accomplish this task.

As I have said before I love Spring and Hibernate; however, there is no Spring support for Hibernate’s pagination API. Why am I am not sure. Maybe they are supporting it now but heres what I did. First I made and abstract object I called ‘Page’. I also have a Solr subclass of this object but I will cover that later.

public abstract class Page {

        return this.results = query.list();
    }
}

Since Spring abstracts your Hibernate interaction with HibernateDaoSupport you dont have to write straight criteria calls to Hibernate if you dont want to. Spring does create simple implementation to allow to write straight HQL and many other functions but not pagination. Rather than tackle this problem at this angle I decided to make the abstract class ‘Page’ that you see above for all my data stores. Anyway, here’s how easy it is to then hit the database with this object properly constructed and have it returned ready for use.

public Page getPageOfThings(int page, int resultsPerPage, String orderBy) {

    PageHibernate newPage = new PageHibernate(
            ”FROM Thing”, page, resultsPerPage);

    getHibernateTemplate().executeFind(newPage);

    List count = getHibernateTemplate().find(“SELECT count(*) FROM Thing”);

    newPage.setTotalCount(Integer.parseInt(count.get(0).toString()));

    return newPage;

}