I have made a first-draft version of xindice that enables binary
resources to be saved in the database. It works, but has exposed an
interesting issue.
I have used separate API calls for binary and xml resources, so that the
ability to add binary resources has no impact on xml performance -- it's
an xml database, after all! The implementation creates (lazily) a
separate b-tree in any collection where binary resources are to be
stored. All binary resources go into the binary-only b-tree, the xml
side never knows it's there. Works great.
The problem comes up when implementing the XML:DB get() method. Store()
and remove() both allow the specification of the type of resource to
operate on, by passing the desired resource type: BinaryResource or
XMLResource. Get() takes only a String key. As a result, the get()
code cannot determine what kind of resource you want, and if the desired
resource is not found in the xml database, the binary database must be
queried before null may be returned. That is, of course, an unacceptable
amount of overhead!
At this point I can think of two possibilities, either or both of which
would solve this problem:
1) Store the binary resources in the b-tree. This requires (based on my
current understanding) one additional byte for each resource, which
isn't much overhead when you consider that a disk access is fairly
probable on any given database request.
2) Change the XML:DB definition so that get() may be called with a
Resource object.
Any thoughts?
Regards,
Gary
