iSite Blog

Honestly, i'm asking...why use Domino?

Right now I have more problems getting iSite to run reliably on Domino than I have advantages by doing so...

At the moment I have several problems related to ft-indexes (not updating, or not being accurate), agents (not running, or not picking up data), profile documents (disappearing from one or more members of the cluster), hanging http-servers (no solution yet, IBM is still trying), recycling of documenthandles and what not.

The stack I would like to run on top of Domino includes Jetty to serve documents trough CORBA, RabbitMQ for messaging, Apache Derby to get control on our profile documents, Quartz to get reliable scheduling and Apache Solr to get ft-indexing sane. Unfortunately this only leaves Domino as a document storage, and to be honest, there are better solutions for that, for example Cassandra or even PostgresSQL.

The stuff that we are using that is reliable is Freemarker, jQuery and jQueryUI...and somewhat "classical" Domino forms, but they are almost impossible to get 100%, and very slow to work with. And don't get me started on xPages, the so-called "solution" to Domino web development. That piece of beta software is buggy, unstable, slow to develop with, and keeps throwing hurdles at you when you develop. No thanks!

Btw, I already have embedded Jetty running, and are testing out Derby, inside the Domino JVM. Seems to be working...

The problem

Observant reader may have noticed that I have gotten the dreaded "NotesException: Notes error: Relational operators are not supported in text fields"

This error has haunted me like the plague, and it happens more often than not in an iSite. I have no idea what's causing it, but scouring around the web yields results claiming it to be related to the field table that notes keeps, and apparently the ft-indexser uses this table when it generates the ft-index for a database.

Cause

This probably happened because I created a replica onto the development environment to test-upgrade this database to the new 6.1. Apparently it seems it found a LastUpdate filed without a date first, and stored this in the field table. the LastUpdate field is the field that keeps the LastUpdated information in iSite. I created an agent that runs trough the database, checking for fields without any value, or with the value set to text. It found a few documents, and I tried to set the value to LastUpdated to see if that fixes the problem, but apparently not.

Solution

The only known solution seems to be to create a new replica. (after removing all non-text variants of this field from the database)