Hi.
On Tue, 22 May 2001 15:29:21 +0200
Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Hi
>
> I'm currently implementing the XML:DB API as a layer on top of JDBC. The
> XML files are stored as blobs. Indexing is done by evaluating several
> predefined XPath statements where the results get written in to
> additional columns on the table. Currently I don't have an
> XPathQueryService but created an SQLSelectQueryService which accepts
> queries in the form of the WHERE-part of an SQL query.
>
> An example:
>
> sqlservice.query("orderid >= 123 AND orderid <= 146");
>
> as an equivalent of:
>
> xpathservice.query("//order[id >= 123 and id <= 146]");
>
>
> My experiences:
>
> 1. It would be nice to have some kind of abstract string-based query
> service so it is easier to switch query languages. I don't have XPath
> right now so I'm starting with SQL. But later I'd like to switch query
> languages. My proposal is pretty simple:
>
> public interface QueryService extends Service {
> ResourceIterator query(String query) throws XMLDBException;
> }
>
> public interface XPathQueryService extends QueryService {
> }
>
> public interface SQLSelectQueryService extends QueryService {
> }
>
> Having this I could write:
>
> String srvtype = "SQLSelectQueryService";
> String myquery = "country = 'fr'";
>
> QueryService service = (QueryService) coll.getService(srvtype, "1.0");
> ResourceIterator results = service.query(myquery);
Well, on the one hand I see the advantage of this object oriented
approach to have a common QueryService interface. On the other hand
I would try to keep the API layer as thin as possible. Your proposal
doesn't functionally extent the current API, you can achieve the same
with the following - and I think that's your current solution:
public interface SQLSelectQueryService extends Service {
ResourceIterator query(String sqlQuery) throws XMLDBException;
}
public interface XPathQueryService extends Service {
ResourceIterator query(String xpathQuery) throws XMLDBException;
}
Don't get me wrong here. I see the advantage of your example above. IMO
the costs (i.e. complexity) outweighs the advantages here. Other ideas?
> 2. It's not so easy to understand why Collection.getResources() returns
> a String[] of IDs and XPathQueryService.query() returns a
> ResourceIterator. In both cases it might be good to have both
> possibilities, first to iterate through the resources and second to get
> a list of resource IDs. My priority lies on the ResourceIterator.
I came across the same. I like the Iterator pattern but I don't know
if it makes sense to return an iterator for each and every method.
> 3. Just an idea: What about a convenience method on QueryService to
> delete resources without having to fetch them in the first place?
>
> public interface QueryService extends Service {
> ResourceIterator query(String query) throws XMLDBException;
> void delete(String query) throws XMLDBException;
> }
Of course you can add a "delete" method (or whatever you need) to your
proposed SQLSelectQueryService interface - no problem so far. The Service
interface was introduced to provide a future-proof extension mechanism.
Today we don't know what functionality the future will provide.
The XPathQueryService provides a read-only interface to XPath, therefore
"delete()" doesn't make sense and "query()" should be the only method
defined at this interface.
So I propose - as already discussed with Kimbro - to provide a Service
interface for the XUpdate specification. This spec provides tags to
modify any XML document (incl. delete) and a Java based implementation
does already exist.
> 4. Wouldn't it be nice to have a set of conformance tests for XML:DB so
> we can improve exchangability between drivers and faciliate and speed up
> the development of drivers? For the Java world this could consist of a
> package of JUnit tests, for example.
This is true. As far as I could see Kimbro already checked in a "simple"
test suite based on JUnit. And Per Nyfelt (are you here Per? :-) started
to implement a test suite for Ozone that could be contributed to XML:DB.
Anyway, every kind of help is welcome and if you're interested to volunteer,
check out the latest CVS and have a look at the sources. Again, any
help is welcome. :-)
> The XML:DB API, so far, is exactly what I need. So I guess the project
> is on the right track.
Great!
Do others have development experiences?
> I'm looking forward to your comments.
>
> Jeremias M�rki
>
> mailto:[EMAIL PROTECTED]
>
> OUTLINE AG
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> Internet http://www.outline.ch
--
______________________________________________________________________
Lars Martin mailto:[EMAIL PROTECTED]
SMB GmbH http://www.smb-tec.com
----------------------------------------------------------------------
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe: mailto:[EMAIL PROTECTED]
Contact adminstrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
----------------------------------------------------------------------
