Using a byte[] as a secondary index's key within the Collection's API

Question

I am using JE 4.1.7 and its Collections API. Overall I am very satisfied with the ease of using JE within our applications. (I need to know more about maintenance, however!) My problem is that I wanted a secondary index with a byte[] key. The key contains the 16 bytes of an MD5 hash. However, while the code compiles without error when it runs JE tell me
Exception in thread "main" java.lang.IllegalArgumentException: ONE_TO_ONE and MANY_TO_ONE keys must not have an array or Collection type: example.MyRecord.hash
See test code below. I read the docs again and found that the only "complex" formats that are acceptable are String and BigInteger. For now I am using String instead of byte[] but I would much rather use the smaller byte[]. Is it possible to trick JE into using the byte[]? (Which we know it is using internally.)
-- Andrew
package example;
import com.sleepycat.je.Environment;
import com.sleepycat.je.EnvironmentConfig;
import com.sleepycat.persist.EntityStore;
import com.sleepycat.persist.PrimaryIndex;
import com.sleepycat.persist.SecondaryIndex;
import com.sleepycat.persist.StoreConfig;
import com.sleepycat.persist.model.Entity;
import com.sleepycat.persist.model.PrimaryKey;
import com.sleepycat.persist.model.Relationship;
import com.sleepycat.persist.model.SecondaryKey;
import java.io.File;
@Entity
public class MyRecord {
@PrimaryKey
private long id;
@SecondaryKey(relate = Relationship.ONE_TO_ONE, name = "byHash")
private byte[] hash;
public static MyRecord create(long id, byte[] hash) {
MyRecord r = new MyRecord();
r.id = id;
r.hash = hash;
return r;
public long getId() {
return id;
public byte[] getHash() {
return hash;
public static void main( String[] args ) throws Exception {
File directory = new File( args[0] );
EnvironmentConfig environmentConfig = new EnvironmentConfig();
environmentConfig.setTransactional(false);
environmentConfig.setAllowCreate(true);
environmentConfig.setReadOnly(false);
StoreConfig storeConfig = new StoreConfig();
storeConfig.setTransactional(false);
storeConfig.setAllowCreate(true);
storeConfig.setReadOnly(false);
Environment environment = new Environment(directory, environmentConfig);
EntityStore myRecordEntityStore = new EntityStore(environment, "my-record", storeConfig);
PrimaryIndex<Long, MyRecord> idToMyRecordIndex = myRecordEntityStore.getPrimaryIndex(Long.class, MyRecord.class);
SecondaryIndex<byte[], Long, MyRecord> hashToMyRecordIndex = myRecordEntityStore.getSecondaryIndex(idToMyRecordIndex, byte[].class, "byHash");
// END

Answer 1

We have highly variable length data that we wish to use as keys. To avoid massive index sizes and slow key lookup we are using MD5 hashes (or something more collision resistant should we need it). (Note that I am making assumptions about key size and its relation to index size that may well inaccurate.)Thanks for explaining, that makes sense.
It would be the whole field. (I did consider using my own key data design using the @Persistent and @KeyField annotations to place the MD5 hash into two longs. I abandoned that effort because I assumed (again) that lookup with a custom key design would slower than the built-in String key implementation.)A composite key class with several long or int fields will not be slower than a single String field, and will probably result in a smaller key since the UTF-8 encoding is avoided. Since the byte array is fixed size (I didn't realize that earlier), this is the best approach.
--mark