1 Reply Latest reply: Oct 12, 2011 9:57 AM by 893028 RSS

    Query container only relative to the Berkeley DB XML Enviroment location.

    893028
      I have been having a great deal of trouble getting any queries to work using the Berkeley DB XML API. I am using Java 7 as my language and Netbeans 7.0.1 as my platform. After lots of experimentation with the Shell and observing its behavior, I seem to have isolated it to my not being able to specify a full absolute path name for my containers. Apparently to use XmlManager.query() or XmlManager.prepare().execute(), I must root the query with either a collection() or doc() entry at the beginning. The problem seems to be that both collection() and doc() only will take a simple filename+extension form for the name of my container. The XmlManager then resolves this name relative to the location of my XmlManager environment. If I specify anything else, I get "Error 6: Invalid URI format [err:FODC0002]" as an XmlException. I have tried various formats of absolute paths for my containers and none of them will work. For my application, the user needs to be able to put his containers anywhere on a local drive. It appears that the only way that I can operate is to put all my containers in that one Environment directory, or possibly one below it. This is a super-serious problem for me if this is true.

      I could find no call in the API to override this behavior. I had hoped that XmlQueryContext.setBaseURI() would do that since it said it was for specifying a URI against which local things would be resolved against. But, any call to it with a directory path also raised the same XmlExpection. Being new with this produce, I am hoping that I am missing something obvious. Can anyone help?

      Edward Fairchild
      fairce@comcast.net
        • 1. Re: Query container only relative to the Berkeley DB XML Enviroment location.
          893028
          I have more information about this problem. It appears to be caused by spaces in the filename or path of the container in forming the collection() prefix in my xQuery. For the following test, I was using a container named "EEF-PGL10GenAncestors Only.gcdb" in my Environment folder. Here is the code that fails.

          XmlQueryContext context = xmlmanGCDB.createQueryContext();
          context.setEvaluationType(XmlQueryContext.Lazy);
          String sContainerName = xmlcontGCDB.getName();
          FileObject foContainer = FileUtil.toFileObject(new File(sContainerName));
          sContainerName = foContainer.getNameExt();
          sContainerName = Util.convertFilepathToURI(sContainerName);
          String sQuery = "collection(\"" + sContainerName + "\")/" + GCDBTAG_INDI;
          if(bDebug) DebugOut.println("sQuery: " + sQuery);
          XmlQueryExpression xmlquery = xmlmanGCDB.prepare(sQuery, context);
          XmlResults xmlresults = xmlquery.execute(context);
          XmlDocument xmldoc = xmlmanGCDB.createDocument();
          boolean bRet = xmlresults.next(xmldoc);

          1. When I run it with the container named above with space and with the Util.convertFilepathToURI() call commented out, I get an XmlException executing the XmlManager.prepare() call. Based on this, I thought that you must be requiring percent encoding of spaces. The exception had Error Code 6: Invalid URI format [err:FODC0002], errcode = QUERY_PARSER_ERROR. The debug line displayed as

          sQuery: collection("EEF-PGL10GenAncestors Only.gcdb")/INDI

          2. So, if you uncomment that Util.convertFilepathToURI() call line and run it again, the debug line displays

          sQuery: collection("EEF-PGL10GenAncestors%20Only.gcdb")/INDI

          but that also caused an XmlException with Error Code 17: EEF-PGL10GenAncestors%20Only.gcdb: container file not found, or not a container, errcode = CONTAINER_NOT_FOUND. So, it is not interpreting the space as a %20 correctly.

          3. Finally, if I take the space out of the filename and rerun, the debug line displays

          sQuery: collection("EEF-PGL10GenAncestorsOnly.gcdb")/INDI

          and everything works just fine. Are you using some other way to encode this space in a container name besides what I have tried? I need some help here folks.

          Edward Fairchild
          fairce@comcast.net