Menu
▾
▴
exist-development
|
From: Andrzej J. T. <an...@ch...> - 2010-02-02 01:01:14
|
It used to be that if you did an: xmldb:store( $col, $doc, $content ) where $content was a string, but an XML string, store() would store the document as XML, not as a binary document. Now it seems that if you do such a store, even though the $content string is valid XML it now stores the document as a binary document. Looks like Gev checked in a change on the 30th that broke the existing behaviour. I'm not convinced that the prior behaviour was a bug when you were passing in a string that was in fact XML. But I've changed my code to pass in a mimetype parameter in our situation to resolve this. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Adam R. <ad...@ex...> - 2010-02-02 10:20:47
|
Or you could call util:parse to convert your xs:string into a node() On 2 February 2010 01:00, Andrzej Jan Taramina <an...@ch...> wrote: > It used to be that if you did an: > > xmldb:store( $col, $doc, $content ) > > where $content was a string, but an XML string, store() would store the document as XML, not as a binary document. > > Now it seems that if you do such a store, even though the $content string is valid XML it now stores the document as a > binary document. > > Looks like Gev checked in a change on the 30th that broke the existing behaviour. > > I'm not convinced that the prior behaviour was a bug when you were passing in a string that was in fact XML. But I've > changed my code to pass in a mimetype parameter in our situation to resolve this. > > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Dannes W. <di...@ex...> - 2010-02-02 11:05:20
|
Do we have junit tests to 'lock' the behaviour? no? gev? D. On Tue, Feb 2, 2010 at 11:20 AM, Adam Retter <ad...@ex...> wrote: > Or you could call util:parse to convert your xs:string into a node() > > On 2 February 2010 01:00, Andrzej Jan Taramina <an...@ch...> > wrote: > > It used to be that if you did an: > > > > xmldb:store( $col, $doc, $content ) > > > > where $content was a string, but an XML string, store() would store the > document as XML, not as a binary document. > > > > Now it seems that if you do such a store, even though the $content string > is valid XML it now stores the document as a > > binary document. > > > > Looks like Gev checked in a change on the 30th that broke the existing > behaviour. > > > > I'm not convinced that the prior behaviour was a bug when you were > passing in a string that was in fact XML. But I've > > changed my code to pass in a mimetype parameter in our situation to > resolve this. > > > > -- > > Andrzej Taramina > > Chaeron Corporation: Enterprise System Solutions > > http://www.chaeron.com > > > > > ------------------------------------------------------------------------------ > > The Planet: dedicated and managed hosting, cloud storage, colocation > > Stay online with enterprise data centers and the best network in the > business > > Choose flexible plans and management services without long-term contracts > > Personal 24x7 support from experience hosting pros just a phone call > away. > > http://p.sf.net/sfu/theplanet-com > > _______________________________________________ > > Exist-development mailing list > > Exi...@li... > > https://lists.sourceforge.net/lists/listinfo/exist-development > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Andrzej J. T. <an...@ch...> - 2010-02-02 15:32:05
|
Adam: > Or you could call util:parse to convert your xs:string into a node() Funny thing is that our code actually did parse the incoming data (comes from an external file, generated by an external system) for other reasons, but the store used the string value rather than the already parsed node() value. All I can say is that this code is a few years old and hasn't been looked at in some time. That's my excuse and I'm sticking to it. ;-) I changed our application code to use the parsed node() for the xmldb:store() this morning, since it will perform better, avoiding the duplicate parsing that eXist would do. This particular routine of ours is used a lot to import data every night, so it made sense to implement this small optimization. Thanks for the comment Adam....made our code better/faster as a result! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Wolfgang M. <wol...@ex...> - 2010-02-02 11:11:25
|
> Now it seems that if you do such a store, even though the $content string is valid XML it now stores the > document as a binary document. > > Looks like Gev checked in a change on the 30th that broke the existing behaviour. The idea was that if you pass in a string without specifying a mime-type, the function would store it as a binary resource instead of trying to parse it as XML. Evgeny explained this to me before his commit and I agreed it would make the function more consistent. We may be wrong though. Wolfgang |
|
From: Andrzej J. T. <an...@ch...> - 2010-02-02 14:59:07
|
Wolfgang: > The idea was that if you pass in a string without specifying a > mime-type, the function would store it as a binary resource instead of > trying to parse it as XML. Evgeny explained this to me before his > commit and I agreed it would make the function more consistent. We may > be wrong though. I don't think it's wrong...in fact, I do believe that it makes the code more "consistent". It was just a surprise that this behaviour changed, which broke our code, after quite a number of years of it working correctly is all. I'm just glad I caught it before we did a deployment in a real environment. As a convenience, it might be useful to try and parse the string and if it parses then store it as xml. Though I'm not really sure on this. In any case, it would probably be useful to clarify the behaviour a bit better in the function documentation so that others don't trip over this. Just came as a surprise is all... -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Evgeny G. <gaz...@gm...> - 2010-02-02 15:12:17
|
2010/2/2 Andrzej Jan Taramina <an...@ch...> > It used to be that if you did an: > > xmldb:store( $col, $doc, $content ) > > where $content was a string, but an XML string, store() would store the > document as XML, not as a binary document. > > Now it seems that if you do such a store, even though the $content string > is valid XML it now stores the document as a > binary document. > > Looks like Gev checked in a change on the 30th that broke the existing > behaviour. > > I'm not convinced that the prior behaviour was a bug when you were passing > in a string that was in fact XML. But I've > changed my code to pass in a mimetype parameter in our situation to resolve > this. > > Did you setup a mime-type for? if no the content will be stored as binary. Before commit if you will try to store a binary content without mime you will have exception, because content will be stored as xml content. What about XML content not in string but in base64 stream? Think if you store XML content not from element() you can use mime -type "text/xml" as 4th parameter. But what mime must you setup, for many binary docs, for example when you trying unzip somewhere into db? ---- Evgeny |
|
From: Andrzej J. T. <an...@ch...> - 2010-02-02 15:44:25
|
Evgeny: > Did you setup a mime-type for? if no the content will be stored as > binary. Before commit > if you will try to store a binary content without mime you will have > exception, > because content will be stored as xml content. Yup...I figured this all out. However, there was no intrinsic mime type, since we were calling the xmldb:store from inside an XQuery which had read the data from an external source. Like I said, I was just surprised that the old behaviour changed is all. > What about XML content not in string but in base64 stream? I agree. That was problematic. > Think if you store XML content not from element() you can use mime -type > "text/xml" as 4th parameter. > But what mime must you setup, for many binary docs, for example when you > trying unzip somewhere into db? True on all counts. Though I wonder if it wouldn't be convenient to try and parse a string if a mime type is not specified, and if it parses, then store it as a text/xml document rather than as a binary document. Most binary types, such as base64, zip files and the like, would fail on the parse very quickly, so it would seem there wouldn't be much overhead in trying the parse first. Wouldn't be hard to implement (the old approach actually did this). Though again, I'm uncertain whether this "convenience" would be a good thing or not. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Evgeny G. <gaz...@gm...> - 2010-02-02 15:55:10
|
> > > True on all counts. > > Though I wonder if it wouldn't be convenient to try and parse a string if a > mime type is not specified, and if it > parses, then store it as a text/xml document rather than as a binary > document. > > Most binary types, such as base64, zip files and the like, would fail on > the parse very quickly, so it would seem there > wouldn't be much overhead in trying the parse first. Wouldn't be hard to > implement (the old approach actually did this). > I want do it too, but before storing/parsing/reading from stream we are creating a XML or binary doc for storing content. Just I don't see how we can do it at one time, because we parsing directly into out stream. ---------- Evgeny |
|
From: Andrzej J. T. <an...@ch...> - 2010-02-02 21:46:28
|
Evgeny: > I want do it too, but before storing/parsing/reading from stream we are > creating a XML or binary doc for storing content. > Just I don't see how we can do it at one time, because we parsing > directly into out stream. There is no stream...it's a string input. So doing a test parse() on it and storing as XML if the parse succeeds, and storing as binary if it fails (eg. catch the exception), is pretty trivial. I don't see what the technical problem is, at least with the xmldb:store() function. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Elliotte R. H. <el...@ib...> - 2010-02-03 10:52:23
|
On Tue, Feb 2, 2010 at 4:46 PM, Andrzej Jan Taramina <an...@ch...> wrote: > There is no stream...it's a string input. So doing a test parse() on it and storing as XML if the parse succeeds, and > storing as binary if it fails (eg. catch the exception), is pretty trivial. Except that standard XQuery 1.0. doesn't have exception handling. I think there's probably an extension floating around somewhere but I remain amazed that anyone could design a language with dynamic errors and not build in exception handling. -- Elliotte Rusty Harold el...@ib... |
|
From: Adam R. <ad...@ex...> - 2010-02-03 12:08:08
|
On 3 February 2010 10:52, Elliotte Rusty Harold <el...@ib...> wrote: > On Tue, Feb 2, 2010 at 4:46 PM, Andrzej Jan Taramina > <an...@ch...> wrote: > >> There is no stream...it's a string input. So doing a test parse() on it and storing as XML if the parse succeeds, and >> storing as binary if it fails (eg. catch the exception), is pretty trivial. > > Except that standard XQuery 1.0. doesn't have exception handling. I > think there's probably an extension floating around somewhere but I > remain amazed that anyone could design a language with dynamic errors > and not build in exception handling. It will be in XQuery 1.1 :-) http://www.w3.org/TR/xquery-11/#id-try-catch In the meantime eXist provides its own try and catch functions... > -- > Elliotte Rusty Harold > el...@ib... > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Andrzej J. T. <an...@ch...> - 2010-02-03 14:01:30
|
Elliotte: > I remain amazed that anyone could design a language with dynamic errors and not build in exception handling. I'm not surprised by anything that comes out of W3C anymore. LOL And as Adam mentioned, the next XQuery standard will include a formal try/catch mechanism. Till then, use eXist's util:catch() function. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X