Project

Profile

Help

XdmDestination doesnt support sequences - Ftr

Added by Anonymous over 15 years ago

Legacy ID: #6519723 Legacy Poster: David Lee (daldei)

First a minor suggestion. XdmDestination (IMHO) should have a constructor with the configuration, otherwise you have to do a bit of overly complex setup to get it to actually work (not documented). ---- XdmDestination d = new XdmDestination(); Configuration config = ... ; // Get my configuration .. try { Receiver r = d.getReceiver(config); PipelineConfiguration pipe = config.makePipelineConfiguration(); r.setPipelineConfiguration(pipe); } catch {} ---- This is definatly non-obvious, and not documented. I only discovered this by some prety complicated trial & error ... It would be nice if XdmDestination could take the Configuration from the get-go. Anyway ... Once I have a XdmDestination ... I'm trying to use it as the target of xpath and xquery. Works great as long as the result of xpath or xquery is a single item. If I generate a sequence it ignores all but the last item. e.g. "1,2" produces "2". This is the same both when writing results one by one or as the result of a XQueryEvaluator.run() call As a feature request, I would love a XdmDestination that can handle sequences as outputs. Until then, I can generate my own sequences, but I have to avoid XQueryEvaluator.run() and instead use the "pull" methods to evaluate a list (or iterator) and store them out to a sequence. Question: Is this vastly less efficient ? or is it equivilent. That is, if I use XQueryEvaluator as an Iterator<> and then append the results into a sequence is causing much more overhead then using XQueryEvaluator.run() (assuming the destination could take a sequence) ? Or is it equivilent ? Thanks for any suggestions.


Replies (7)

Please register to reply

RE: XdmDestination doesnt support sequences - Ftr - Added by Anonymous over 15 years ago

Legacy ID: #6522621 Legacy Poster: Michael Kay (mhkay)

It shouldn't be necessary for the XdmDestination to know about the Configuration. I suspect that whatever code called getReceiver() then used the resulting Receiver without first initializing its PipelineConfiguration. Was that your code or mine? I think it would be more robust if the getReceiver() call initialized the PipelineConfiguration rather than relying on the caller to do so - that's what other implementations of getReceiver() appear to do, and is the main justification for supplying the Configuration as a parameter to the method. A cleaner design would probably have been to construct Destination objects using factory methods on the Processor, but that would have made it difficult to introduce user-defined Destination classes. As for writing multiple nodes, I guess there's some logic in that - but you can always use XQueryEvaluator.iterate() to return multiple nodes from a query.

RE: XdmDestination doesnt support sequences - Ftr - Added by Anonymous over 15 years ago

Legacy ID: #6522805 Legacy Poster: Michael Kay (mhkay)

>That is, if I use XQueryEvaluator as an Iterator<> and then append the results into a sequence is causing much more overhead then using XQueryEvaluator.run() (assuming the destination could take a sequence) ? >Or is it equivalent ? Using the iterate/evaluate is more efficient than run() if the query is selecting existing nodes from the input, because it avoids creating a copy. If you are constructing new nodes in the query, then it's equivalent. But run() is more efficient in the case of a query that is constructing a new document and serializing it, because it avoids building the result document as a tree.

RE: XdmDestination doesnt support sequences - Ftr - Added by Anonymous over 15 years ago

Legacy ID: #6523058 Legacy Poster: Michael Kay (mhkay)

Actually the specification of Destination.getReceiver() does currently say: It is the caller's responsibility to initialize this Receiver with a {@link net.sf.saxon.event.PipelineConfiguration} before calling its <code>open()</code> method. If you find a Saxon path that is not doing this, please let me know.

RE: XdmDestination doesnt support sequences - Ftr - Added by Anonymous over 15 years ago

Legacy ID: #6524925 Legacy Poster: David Lee (daldei)

Saxon code, not mine. Here's a call path if I dont set the configuration it causes a null pointer except. ---- call statck --------- TinyTree.addNode(short, int, int, int, int) line: 330 TinyTree.addDocumentNode(TinyDocumentImpl) line: 303 TinyBuilder.startDocument(int) line: 134 NamespaceReducer(ProxyReceiver).startDocument(int) line: 98 TreeReceiver.startDocument(int) line: 105 Processor.writeXdmValue(XdmValue, Destination) line: 216 xpath.run(List<XValue>) line: 177 ---------- My code: processor.writeXdmValue(item, ser ); where item is a XdmValue and ser is new XdmDestination() with no further tricks. Your code: documentNumber = config.getDocumentNumberAllocator().allocateDocumentNumber(); Crash, no config.

RE: XdmDestination doesnt support sequences - Ftr - Added by Anonymous over 15 years ago

Legacy ID: #6525075 Legacy Poster: Michael Kay (mhkay)

OK thanks, I've raised a bug and a patch on this: https://sourceforge.net/tracker2/?func=detail&amp;aid=2636940&amp;group_id=29872&amp;atid=397617

RE: XdmDestination doesnt support sequences - - Added by Anonymous over 15 years ago

Legacy ID: #6530883 Legacy Poster: David Lee (daldei)

Thanks for the fix ! I havent looked at the source of the patch yet, but could you verify that the XdmDestination.reset() method preserves the configuration (or that none is needed after calling reset()) Thanks ... I mention this because I just ran into the side effect of the current code that calling reset() clears the configuration I previously set.

RE: XdmDestination doesnt support sequences - - Added by Anonymous over 15 years ago

Legacy ID: #6534321 Legacy Poster: Michael Kay (mhkay)

The patch doesn't cause XdmDestination to know or remember the configuration, instead it causes Processor.writeXdmValue() to set the PipelineConfiguration in the Receiver returned by XdmDestination.getReceiver() (which the documentation says it should do). It's possible that other paths could suffer the same problem, and I'm changing the code in the next release so that getReceiver() itself takes responsibility for ensuring the PipelineConfiguration is already set in the returned Receiver.

    (1-7/7)

    Please register to reply