Hi,
Inspired by the SixDML proposal I've been looking some more into the
XMLD:DB API specification(since its partially based on the XML:DB core
API spec) and have number of remarks about it, though I did not yet have
time to read the specification thoroughly, so expect some more.
Unfortunatly I also didn't have enough time to think of alternatives the
things I have a problem with.
Some general remarks:
* Resource and Services are perfectly abstract names but its hard to
imagine for a user what they mean. I'm in favor of more specific names,
to make it easier for users to imagine what they stand for (I only have
to figure out what the right names would be).
* As Dare Obasanjo already mentioned the tying of services to
collections is not very practical. I think this is definitly something
that should be changed.
Interface specific remarks:
Collection interface
* I think the behavior and interface of the getServices method should be
changed, because:
- Each instance of a service could possibly take up resources, in which
case you would want to instantiate those services lazy whenever
getService is called.
- It's not likely you need them all at once.
- If its meant for checking the types of services supported by the
collection (though personally I do not think that services should be
coupled to collections at all) then it could return only the names of
the services it supports.
* I'm not quite sure about the use of
getResourceCount/getChildCollectionCount, since in the case of X-Hive it
involves counting the resources which of course has a bad performance
characteristic.
CollectionManagementService interface
* If think this interface is overkill, why not add the createCollection
and removeCollection methods to the CollectionInterface? If not should
it then check if the collection it operates on is still open?
ResourceSet interface
* getResource(long item) will only have a good performance if there's a
random access list behind the resource set.
* getSize will only have a good performance if there's a list behind the
resource set
When evaluating queries lazy (not always completely possible: for
instance if the end result, or temporary results need to be sorted), you
typically do not want to gather results in a list, but return them one
by one in using an iterator.
What you typically want to prevent is that users use code like this:
ResourceSet rs = ...;
for (long i = 0; i < rs.getSize(); i++) {
Resource r = rs.getResource(i);
}
to iterate over the query results when the query is lazy evaluated.
Because this would mean that the result set should first gather al the
query results which would essentially mean that the results are iterated
twice (and you may not have enough working memory to get all the results
from the database).
Though of course these methods could be useful when there's a list
behind the resource set (for instance when the end result needed to be
sorted) in those cases you can request the size without a performance
penalty.
So maybe some method should be added to see if the resourceset is lazy
or not?
* getIterator returns a ResourceIterator. I'm more in favor of returning
a java.util.Iterator (I don't see the cast that becomes necessary as a
problem), and renaming the method to iterator() because that's more like
other java interfaces, though I understand that this just a matter of
taste, and having an own interface for it could make porting the API to
other platforms than java easier.
* The ResourceIterator interface
If not replaced by java.util.Iterator I would prefer if this interface
would have methods named next() and hasNext() instead of nextResource()
and hasMoreResources().
An finally I have a question, is there a test suite that tests
conformance to the API?
Kind regards,
Arno de Quaasteniet
X-Hive Corporation
+31 (0)10 710 86 24
http://www.x-hive.com
[EMAIL PROTECTED]
----------------------------------------------------------------------
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe: mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
----------------------------------------------------------------------
