Jofti

FAQ

The listing below provides some of the Frequently asked Questions about JOFTI. More detailed FAQs on coding and support can be found in the support section.

If you have any other questions feel free to mail enquiries@jofti.com

Design

Is Jofti a Text Indexing Engine?

In a word no. Jofti is not really aimed at the same types of problem that you would use a Text indexing engine such as Lucene for.

Text indexers are excellent at searching for words (or partial words) inside files or large Strings. Jofti is focused on indexing attributes of an object by type. So that a Date, or a Long or an int is able to be searched according to the comparison rules of that type, not just the lexical value of the data.

In addition, Jofti, does not store its indexes out to disk for updating and does not have a crawl type idea built into it. Rather it acts as a wrapper to a Cache implementation and updates the index as objects are put and removed from the Cache.

Is Jofti clusterable?

Jofti's clustering depends upon the clustering capabilities of the Cache implementation. For a a simple HashMap, which has no clustering, then instances on different machines will not be able to share data. For OSCache the inserts are not replicated but the removals are. So the index at each node will be updated with global removes but not updates. Tangosol Coherence provides excellent clustering, EHCache (1.2) can be configured to just replicate removals or all operations, and, like JBossCache, both provide a full clustering behaviour and therefore changes at one node will be propogated to another node, which will then use the callbacks in Jofti at that node to update that instance.

It is important to realise that it is not necessary to have Jofti at each node you run the clustered cache on - you mught only want it on one node, which means you can just configure it on one node and ignore the other nodes.

What Caches are Supported?

Currently Jofti supports Tangosol Coherence, EHCache, OSCache, JBossCache and IBM's ObjectGrid in addition to which any Map type collection structure (HashMap,TreeMap,LinkedHashMap etc) is also supported. Support for other Caches can be added by developing an adapter. Although this can be complex and requires a reasonable level of knowledge about Jofti's indexing.

Why is SwarmCache/JCache not supported?

The answer is that for version 1 of Jofti we decided to support a subset of the most popular Caches. It was felt that SwarmCache and JCache lack some features that would make support slightly difficult (things such as callbacks on element expiry and neither project has had much activity in the last couple of years).

Can I use more than one type Cache in the same instance?

Yes you can, Jofti can easily be configured to have its indexes back onto different caches in a single instance and also provides the same API for each Cache. So you can use OSCache to replicate one set of data and EHCache to store another set locally for better performance in the same instance of Jofti and the API is identical. Indeed, it then becomes easy to swap out one type of cache for another at runtime using config files rather than change the code.

JBossCache requires a slightly different API for usage as it has the concept of a namespace, therefore each of the methods for this API requires an additional namespace parameter. Other than that the code would be identical to using one of the other Cache implementations. See the User Guide section Simple Usage with Preconfiguration for details.

Isn't this similar to JDO?

Not really. JDO is an API for persistence, although query and retrieval is part of that specification. Jofti does not deal with persiting data at all, its function is to index and support querying of Objects in a Cache or Map type structure. If your cache supports persistence then that is an issue for your Cache, Jofti does not really care one way or the other. Similarly, that is why Jofti has not implemented JDOQL. Given the near finalisation of the EJB3 spec version 1.2 now includes support for EJB3 QL format queries and provides some extra functionality leveraged off this change.

How is this different than JoSQL?

JoSQL is a product for iterating over lists and other collections using an SQL like syntax. It has no indexing and is aimed at a different problem. Jofti is targeted at indexing objects in a Cache using the object attributes and performs no iterations directly on the cache. The SQL interface Jofti uses is merely an easy to use query language that is based on SQL, it is not central to the idea of Jofti, as the inclusion of EJB3 QL support in the latest version shows. Other query language types (such as XPath) are also able to be plugged into Jofti, and will be in a future release.

Can I use this with a bespoke Cache Implementation?

Yes, although in order to do this it would be necessary to write an additional adaptor for Jofti to integrate with your Cache solution. The developers are happy to help out and we offer consulting and advice for those companies that wish to add the indexing and searching to their own products. See the license page for details.

Usage

Do I need to remove an entry before replacing it?

No you do not. Jofti will remove the previous indexed values when you put a value over an existing key.

If I change an attribute directly in an Object that I have previously indexed will it be picked up by Jofti?

No, you will need to call cache.put() again in order for the change to be picked up by the index. If you change an object outside the Cache by retaining a reference directly to it and changing a value this will not be picked up by Jofti. In addition, prior to calling put again on the Cache the Object may well be returned from a search when the attribute change means that it should not.

In order to deal with this Jofti can be configured with the fact that the Objects need to be checked for attribute changes when searching (Mutability). You can tell Jofti to check for mutable object changes by setting the mutable-value flag to true in the config. See the Mutable objects in Jofti entry in the user guide for more details.

This will prevent Jofti returning false positives if the Object is changed directly, however, it will not show up under the new attribute until you call cache.put() again.

Why are all the attributes that are indexed required to be Comparable?

It is important to clarify this. Jofti has a requirment that individual attributes that are specified in a Tree Index must implement Comparable, however this does not mean that the Objects containing these attribute need be Comparable. For example you might have a Person Object with a lastName attribute of type java.lang.String. The lastName attribute (if you want to use it as an indexed field must be comparable - which it is as it is a String), but the Person Object does not have to be Comparable. Indeed, any other attributes that are not indexed can be whetever type you want as they are ignored by Jofti.

So as to the Comparableness for the attributes. There are really a couple of reasons for this.

• Comparable objects can be searched by range (>,>=,<,<=) as well as == and !=.
• Most of the common field types in Java actually end up being inherently comparable types. E.g.
  
  • java.lang.String
  • java.lang.Integer
  • java.lang.Double
  • java.lang.Float
  • java.lang.Long
  • java.lang.Short
  • java.lang.Byte
  • java.math.BigInteger
  • java.math.BigDecimal
  • java.util.Date
  • java.sql.Timestamp
  • java.net.URI
• Primitive types all (apart from Boolean) can be boxed into their comparative wrapper types, which all implement Comparable.

Therefore it was felt that the restriction was not that onerous and that User Defined types in many cases could also implement Comparable. It is somewhat analagous to the hashCode and equals requirements for Map.

In subsequent versions of Jofti there will be other index types available (such as a hash-based) which will mean that the comparable requirement will not apply for those types of indexes.

Can I Index a Cache that already contains data?

Yes you can. Jofti will scan the cache and insert the Object that already exist in the Cache into the index.
See the User Guide Indexing already populated Caches for more details.

There are a couple of things to be careful of with this approach.

• OSCache does not support this - as it is not possible to find out the existing key set.
• Objects in the Cache under Keys that are not Comparable will be ignored by Jofti (this does not apply to JBossCache).

Can I use Jofti with the Spring Framework?

Yes you can. Jofti has been designed to support easy integration with Dependency Injection frameworks and can be configured in a number of ways.
See the User Guide Dependency Injection for more details.

General

Why is Jofti dual licensed and not just open-sourced?

Jofti is intended to be used by other open-source projects that are GPL compatible and this license option means that any software using Jofti in this way will remain open-source (which is more difficult to achive using LGPL, or the Apache license).

However, for those companies or organisations that do not want to be subject to the GPL requirements a Commercial license is offered. This allows us to continue development of the product in both the open-source and Commercial arenas. However, we do charge for product support as, unfortunately, Jofti does not have full time developers who are employed by a large commercial organisation to develop open source software. (like a number of the most notable open source projects).

While a number of other open-source products have a significant developer-time input, and generate revenue through consulting, Jofti does not see this as a viable model for this type of software and so has adopted a similar approach to companies such as MySQl or Sleepycat, which are good examples of dual open source and commercial software products founded on a reasonable ethos.

Do I need to purchase a support license?

You do not have to purchase support for either the open-source or commercial licensed versions of the product, however, while we will endeavour to answer as many questions as possible, queries that are from companies, organisations or individuals that do not have a support liense will be dealt with in an ad-hoc manner and it is prefered that such support issues are addressed via the forums. Commercial support provides guranteed response times to queries, direct email support and involvement by the developers who wrote the product on your issue.