I am new to Berkeley DB - looked at the new Data Persistence Layer and
seemed really simple so am trying to use it. In general, I like it a
lot and everything seems to work fine. The one area where instructions
and docs seem weak is in dealing with class hierarchies. In particular,
I am trying to implement Polymorphism within a single Entity and
running into trouble. Docs seem to indicate this can be done, but am
not quite able to do it:

(http://www.sleepycat.com/jedocs/java...el/Entity.html)

I have two classes - Employee and Manager which extends Employee.
Employee is declared as an Entity and Manager is declared to be
persistent. Manager declares a SecondaryKey that I want to use to
access all managers. Relevant code snippets below:

@Entity
public class Employee {

@PrimaryKey
EmployeeID id;

....

}

@Persistent
public class Manager extends Employee {

@SecondaryKey(relate=ONE_TO_ONE)
String department;

....

}

Now, I want to create a secondary index to look for managers and am not
able to do this. Here is what I tried:

EntityStore store = ...
PrimaryKey<EmployeeID, Employee> employeesById =
store.getPrimaryKey(EmployeeID.class,
Employee.class);
SecondaryKey<String, EmployeeID, Employee> managersByDept =
store.getSecondaryKey(employeesById,
String.class, "department");

The second statement throws an exception saying department was not
recognized as a SecondaryKey in the entity Employee (I can see that
would happen because department is not a field in Employee). However, I
cannot seem to specify Manager as the Entity because I get an exception
saying Manager is not an entity. Again, I can see that would happen
because only Employee is defined as an Entity. So I'm stuck not knowing
how to get this secondary key working - maybe I'm missing something
obvious - any help would be much appreciated.

Regards,

shankar

Hello Shankar,

It looks like you have run into a bug in the beta release of the
Persistence API -- we apologize for that. We will work on a fix and
make it available to you, as well as including the fix in the next
release of Berkeley DB Java Edition. I will post back to this forum
when the fix is available.

In the mean time, there is a work around: You can explicitly register
the Manager class and any other subclass containing a secondary key.
To do this, you have to explicitly create the model object as shown
below, rather than allowing an AnnotationModel to be created by
default:

/* Create the model explicitly and register the subclasses */
EntityModel model = new AnnotationModel();
model.registerClass(Manager.class);

/* Use the model to configure the store */
StoreConfig storeConfig = new StoreConfig();
storeConfig.setAllowCreate(true);
storeConfig.setModel(model);
EntityStore store = new EntityStore(..., storeConfig);

Please let me know if this does not work for you.

Mark

Mark,

Thanks much for tracking that down so quickly - I verified it works.
BTW, I
love what you guys have done with the DPL - very cool !! I assume the
fix
will be in the next rev of JE ...

One nit - when I build a secondary index for my Manager class, I am
still
forced to declare them as Employees because the secondary index builds
off the primary index. This requires me to do casts to Manager on the
results.
Any chance you can declare the generic parameters for the secondary
index
as <SK, PK, "T extends Entity"> ? This will allow one to avoid the
casts and
I assume also allow your runtime to better check the validity of the
SecondaryKey
field name I pass in ...

Regards,

shankar

mark.hayes (AT) oracle (DOT) com wrote:

shankar wrote:
You're welcome. Hey, thanks for the positive feedback, it's great to
hear! Yes, the fix will be in the next rev of JE.

It turns out that the Class of the entity subclass (Manager.class)
needs to be passed as a parameter when getting the secondary index.
This is because, prior to this point, that class may not be known to
the DPL. (There is no practical way in Java to get all the subclasses
of a given class.) In order to find the key field (department) the DPL
must know about the Manager class somehow. This is why calling
registerClass is a workaround.

By adding a new method to get the secondary index with an extra
parameter for the subclass, we are also able to return an index with
that subclass as the entity class -- the E type parameter. I believe
this is what you're asking for above.

I've called this method getSecondarySubclassIndex and it is used as
follows:

SecondaryIndex<String, EmployeeID, Manager> managersByDept =
store.getSecondarySubclass(employeesById, Manager.class,
String.class,
"department");

This seems to solve both issues. Do you agree?

Mark

Mark,

This proposal works perfect. Looking forward to seeing it implemented
in the next release of JE :-)

Regards,

shankar

mark.hayes (AT) oracle (DOT) com wrote: