Yes, I'm here :) I was half way through creating the tests for level 0 and started on level 1 but had to shift attention away because of work. I'll be able to give it another stab this week-end. Sorry for the delay.
Best regards, Per > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Lars Martin > Sent: den 22 maj 2001 16:31 > To: [EMAIL PROTECTED] > Subject: Re: Experiences with XML:DB > > > > 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/ > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
