Help to design repository using BerkeleyDB

Question

Hi,
I am trying to design a repository using BerkeleyDB but not sure what will be the best design.
Here is the scenario:
I have one Schema under which we can multiple classes of Java Objects to be stored.
Eg: Under Schema1, we can store any of the objects from three classes A, B, C.
Alll have the same schema.
I want to persist all the objects of any of the class A, B, C coming in the system.
Key is the time at which they enter the system.
So key is time and value is Instance of any of the object A, B,C.
So we can have duplicates i.e. multiple instances coming at the same time.
A,B,C are POJO Java Objects so I don't have control over their implementation.
From my understanding
Schema should map to the Environment.
Within one Environment, we can have different databases for each A, B, C since they have different class definitions.
What should I use DPL or Base APIs?
If using Base API's how to write MyTupleBinding because the definition of the class can be available after system gets configured.
Is there any way to write a generic TupleBinding class which can convert any Java Object to an Entry and vice versa.
If using DPL how to define Entity, Persitent Entities etc.
User can query on any column of a POJO object so we have no information about secondary keys.
Please provide me your suggestions.

Answer 1

Hi,
Key is the time at which they enter the system.So key is time and value is Instance of any of the object A, B,C.
So we can have duplicates i.e. multiple instances coming at the same time.>
Instead of using the time only as the key, use a two part key {time, sequence} to make the key unique. That will give you a unique primary key and also allow you to lookup records by time using the first part of the key.
A,B,C are POJO Java Objects so I don't have control over their implementation.Can you add annotations to these classes? Are they Serializable?
From my understandingSchema should map to the Environment.
Within one Environment, we can have different databases for each A, B, C since they have different class definitions.>
Yes.
What should I use DPL or Base APIs?If you can add annotations to the classes, use the DPL. If not, and the classes are Serializable, you could use SerialBinding. Otherwise, you'll have to write tuple bindings.
If using Base API's how to write MyTupleBinding because the definition of the class can be available after system gets configured.Is there any way to write a generic TupleBinding class which can convert any Java Object to an Entry and vice versa.>
The only way to do that is use Java reflection to discover the fields in the classes. This is a lot of work, but is how such things are done in Java.
If using DPL how to define Entity, Persitent Entities etc.If you can't add annotations, you could write a custom subclass of EntityModel. But that's an advanced use case, and it won't work if there is no unique primary key field in each class.
User can query on any column of a POJO object so we have no information about secondary keys.You can do one of the following:
1) Define no secondary keys and iterate over all records in a database when doing a query (queries are expensive if there are lots of records).
2) Define every field as a secondary key (writes are expensive and lots of disk space is used if there are lots of fields).
3) Try to dynamically determine when queries are frequently done on a field, and dynamically add a secondary key at that time (lots of work to implement).
Please provide me your suggestions.Please answer my questions above and then I'll suggest an approach. If the POJO classes are required to be Seriallizable, your task will be greatly simplified.
--mark