Hello Rainer, Welcome to BaseX and I hope we can help you with your troubles :) If you are running an XPath like "doc('catalog')//article" and you get a null result, I suspect that your xml document uses some namespaces. If * article* is not in the default namespace, you will correctly retrieve a null value as result. Using the wildcard namespace should resolve your issue, i.e. using "doc('catalog')//*:article". If this does not resolve your issue, it would be nice to have a SSCEE [1] and your xml document. Without the data it is quite difficult to guess the root of the problem. I personally never used the DOM for processing as XQuery itself is very nice. Indeed, using iteration and .toJava() should return just this single node. Maybe someone else on the list could help here. I agree that the help could be extended. However, there is some extensive example source code for Java available at https://github.com/BaseXdb/basex-examples/tree/master/src/main/java/org/base.... Maybe you could have a look at this source code. Hope this helps. Cheers, Dirk [1] http://sscce.org/ On Fri, Oct 12, 2012 at 9:58 PM, Rainer Klute <rainer.klute@gmx.de> wrote:

Hi,

I did some first steps with BaseX, but unfortunately I was not very successful.

I have a really large XML file which does not fit into memory, and I would like to navigate it as a DOM. My hope was that I could store it as a BaseX database, retrieve the root element as a org.w3c.dom.Node, and then start navigating down and up the DOM as needed without having to have the whole stuff in memory.

I tried something like this:

QueryProcessor processor = new QueryProcessor("doc('catalog')/*", context); Iter iter = processor.iter(); Item item = iter.next(); Object node = item.toJava();

According to the debugger the item variable indeed denoted my root element. However, when calling item.toJava() not only that very node was returned. Instead BaseX obviously tried to retrieve the whole DOM – which was just the very thing I wanted to avoid.

Am I doing something wrong here? Or is this an unforeseen use case?

By the way, I also had trouble getting any result at all. Only with "doc('catalog')/*" I got an item that was not null. When I tried to retrieve all elements named "article" using "doc('catalog')//article" the item was null. I also tried the item.iter() in order to find a node's children. However, it turned out that item().iter().next() == item.

And I had quite a tough time fiddling around with the documentation and with the JavaDoc. While the documentation puts a lot of effort into XQuery, it remains unclear to some extend how to do some basic stuff with BaseX programmatically. This is a hurdle for the BaseX beginner. Some more Java examples and explanations would be nice showing how to connect to the database, submit a query and process the result. Currently the examples show only how to dump a query result to System.out. It would be interesting to learn about processing it further – see my troubles with Iter.

--

Best regards Rainer Klute

_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

-- Dirk Kirsten, BaseX GmbH, http://basex.org |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22

Dear Rainer,

I have a really large XML file which does not fit into memory, and I would like to navigate it as a DOM. My hope was that I could store it as a BaseX database, retrieve the root element as a org.w3c.dom.Node, and then start navigating down and up the DOM as needed without having to have the whole stuff in memory.

By accident, a previous version of BaseX was working as doing exactly what you were describing. In more recent versions, the DOM node is completely materialized in memory, because lazy processing was causing too many unwanted side effects regarding concurrency and node caching. While the resulting representation takes less space than the original Java DOM representation, and is faster in many cases, it still takes about 2-3 times of the size of the textual representation. What you can do, however, and what we regularly do, is using our internal node representation. A small example is shown in the following: Context context = new Context(); QueryProcessor processor = new QueryProcessor("doc('catalog')/*", context); context.register(processor); Iter iter = processor.iter(); Item item = iter.next(); if(item instanceof ANode) { ANode node = (ANode) item; System.out.println("Name: " + node.qname()); for(final ANode child : node.children()) { System.out.println("- Child: " + child); } } processor.close(); context.unregister(processor); context.close(); Please remember to close the processor after having requested all nodes; otherwise, the database will be kept open. Using context.register(), you can be sure that no other write operation will modify your data as long as you're requesting it. If concurrency is no issue, feel free to remove the (un)register calls.

And I had quite a tough time fiddling around with the documentation and with the JavaDoc. While the documentation puts a lot of effort into XQuery, it remains unclear to some extend how to do some basic stuff with BaseX programmatically. This is a hurdle for the BaseX beginner.

Absolutely true; our documentation is rather sparse when it comes to our internal low level API, and we are well aware that many of our users would benefit from some more brain food reg. our architecture. As a matter of fact, writing a good documentation takes a lot of resources, which is why we are always thankful for external contributions. Still, we are doing our best to document our source code as good as possible. It may help a lot when you want to leave our high-level APIs, such as the client APIs and XQJ. Christian