[MonetDB-users] PF: warning: query will always return an error
Hello,
In stable branch + milprint_summer, executing the following query (you need to have a "hello.xml" doc shredded in collection "hello"):
let $path := 'backup/test/hello/' let $index := element documents { for $document at $pos in pf:documents('hello') let $uri := concat($path, string(10000 + (($pos div 10000)) cast as xs:integer), '/', string($pos) , '.xml') return (text { " " }, element document { attribute uri {$uri}, $document/text() }), text { " " } } return (put($index, concat($path,'documents.xml')), for $document in $index/document return put(exactly-one(doc(string($document))), exactly-one($document/@uri)))
Results in the first 'put' is done, while the second 'put' is not executed, actually, the MIL code generated by 'pf' contains only translation of (the first) one 'put'. Also, the query gives a warning: query will always return an error If I comment out the first 'put', the second 'put' in the for-loop get executed, *without* the warning.
Executing a similar query:
(put(<a/>, "a.xml"), for $n in ("b.xml", "c.xml") return put(exactly-one(doc("hello.xml")), $n) )
also results in the warning, however, the generated MIL code contains translation of both 'put' and three documents are put in dbfarm.
I'd like to know why the first query fails, and what has triggered the warning. Thanks a lot!
Kind regards,
Jennie
Hi Jennie,
I can only answer the second question (what triggered the warning): In the type checking a warning is triggered in case we get back the type none+ because we assumed at some time that type none represents an error. Because you had to instances of put you got the result type none+ (as with query '(put (<a/>, "foo"), put (<b/>, "bar"))').
The answer to the first question is probably hidden in milprint_summer.c and the way it generates code for put() as the generated core code still contains both calls to put().
Jan
On 07/04/2008 03:01 PM, Ying Zhang wrote with possible deletions:
Hello,
In stable branch + milprint_summer, executing the following query (you need to have a "hello.xml" doc shredded in collection "hello"):
let $path := 'backup/test/hello/' let $index := element documents { for $document at $pos in pf:documents('hello') let $uri := concat($path, string(10000 + (($pos div 10000)) cast as xs:integer), '/', string($pos) , '.xml') return (text { " " }, element document { attribute uri {$uri}, $document/text() }), text { " " } } return (put($index, concat($path,'documents.xml')), for $document in $index/document return put(exactly-one(doc(string($document))), exactly-one($document/@uri)))
Results in the first 'put' is done, while the second 'put' is not executed, actually, the MIL code generated by 'pf' contains only translation of (the first) one 'put'. Also, the query gives a warning: query will always return an error If I comment out the first 'put', the second 'put' in the for-loop get executed, *without* the warning.
Executing a similar query:
(put(<a/>, "a.xml"), for $n in ("b.xml", "c.xml") return put(exactly-one(doc("hello.xml")), $n) )
also results in the warning, however, the generated MIL code contains translation of both 'put' and three documents are put in dbfarm.
I'd like to know why the first query fails, and what has triggered the warning. Thanks a lot!
Kind regards,
Jennie
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
Hi Jan,
we checked this with Jennie yesterday and as Jennie correctly pointed out the fn:put function has changed in the specification to have a returning type of an empty sequence rather than none. By changing the returned type in semantics/xquery_fo.c for function fn:put to something random (ex. PFty_anyNode) it did "work". However, to have a correct fix, is there any way to define that the return type is an empty sequence?
lefteris
On Tue, Jul 8, 2008 at 9:59 AM, Jan Rittinger rittinge@in.tum.de wrote:
Hi Jennie,
I can only answer the second question (what triggered the warning): In the type checking a warning is triggered in case we get back the type none+ because we assumed at some time that type none represents an error. Because you had to instances of put you got the result type none+ (as with query '(put (<a/>, "foo"), put (<b/>, "bar"))').
The answer to the first question is probably hidden in milprint_summer.c and the way it generates code for put() as the generated core code still contains both calls to put().
Jan
On 07/04/2008 03:01 PM, Ying Zhang wrote with possible deletions:
Hello,
In stable branch + milprint_summer, executing the following query (you need to have a "hello.xml" doc shredded in collection "hello"):
let $path := 'backup/test/hello/' let $index := element documents { for $document at $pos in pf:documents('hello') let $uri := concat($path, string(10000 + (($pos div 10000)) cast as xs:integer), '/', string($pos) , '.xml') return (text { " " }, element document { attribute uri {$uri}, $document/text() }), text { " " } } return (put($index, concat($path,'documents.xml')), for $document in $index/document return put(exactly-one(doc(string($document))), exactly-one($document/@uri)))
Results in the first 'put' is done, while the second 'put' is not executed, actually, the MIL code generated by 'pf' contains only translation of (the first) one 'put'. Also, the query gives a warning: query will always return an error If I comment out the first 'put', the second 'put' in the for-loop get executed, *without* the warning.
Executing a similar query:
(put(<a/>, "a.xml"), for $n in ("b.xml", "c.xml") return put(exactly-one(doc("hello.xml")), $n) )
also results in the warning, however, the generated MIL code contains translation of both 'put' and three documents are put in dbfarm.
I'd like to know why the first query fails, and what has triggered the warning. Thanks a lot!
Kind regards,
Jennie
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
-- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 07/08/2008 10:08 AM, Lefteris wrote with possible deletions:
Hi Jan,
we checked this with Jennie yesterday and as Jennie correctly pointed out the fn:put function has changed in the specification to have a returning type of an empty sequence rather than none. By changing the returned type in semantics/xquery_fo.c for function fn:put to something random (ex. PFty_anyNode) it did "work". However, to have a correct fix, is there any way to define that the return type is an empty sequence?
You probably mean PFty_empty().
On Tue, Jul 08, 2008 at 10:48:25AM +0200, Jan Rittinger wrote:
On 07/08/2008 10:08 AM, Lefteris wrote with possible deletions:
Hi Jan,
we checked this with Jennie yesterday and as Jennie correctly pointed out the fn:put function has changed in the specification to have a returning type of an empty sequence rather than none. By changing the returned type in semantics/xquery_fo.c for function fn:put to something random (ex. PFty_anyNode) it did "work". However, to have a correct fix, is there any way to define that the return type is an empty sequence?
If I define the return type of fn:put as PFty_star( PFty_xs_anyElement ()), both of my problems disappear, i.e. the warning is gone, and my first query also gives correct results.
You probably mean PFty_empty().
This might indeed be the type we are looking for, however, in the final generated MIL code, it contains no translation for fn:put() at all. The simplification/optimization steps didn't know that this "senseless" function has some side effect:)
I will try to find where fn:put has been simplified, or maybe Jan already has an idea?
Jennie
-- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On Tue, Jul 8, 2008 at 5:19 AM, Ying Zhang Y.Zhang@cwi.nl wrote:
You probably mean PFty_empty().
This might indeed be the type we are looking for, however, in the final generated MIL code, it contains no translation for fn:put() at all. The simplification/optimization steps didn't know that this "senseless" function has some side effect:)
I will try to find where fn:put has been simplified, or maybe Jan already has an idea?
Hi!
empty-sequence() doesn't seem to be the right return type for fn:put(). Pathfinder decides the validity of updating expressions slightly different than the W3C specs (and, in my eyes, much more consistent). According to the W3C, updating expressions have the return type empty-sequence() and there are syntactical constraints that prohibit mixtures of updating and non-updating expressions.
Pathfinder, by contrast, knows an additional type, separate from any other type: statement (accessible via PFty_stmt() or something like that). Correctness of a query is then decided based on types. This should also be the right return type for fn:put().
The W3C specification even seems somewhat contradictory. According to static typing rules, most situations where an expression can statically be determined to yield the empty sequence are actually considered a type error. In consequence, there must not be a function whose return type is empty-sequence(). Pathfinder doesn't strictly implement this part of the static typing feature.
Best regards,
Jens
On 2008-07-08 13:55, Jens Teubner wrote:
On Tue, Jul 8, 2008 at 5:19 AM, Ying Zhang Y.Zhang@cwi.nl wrote:
You probably mean PFty_empty().
This might indeed be the type we are looking for, however, in the final generated MIL code, it contains no translation for fn:put() at all. The simplification/optimization steps didn't know that this "senseless" function has some side effect:)
I will try to find where fn:put has been simplified, or maybe Jan already has an idea?
Hi!
empty-sequence() doesn't seem to be the right return type for fn:put(). Pathfinder decides the validity of updating expressions slightly different than the W3C specs (and, in my eyes, much more consistent).
The thing is, fn:put() is *not* an updating expression. It is defined in the same document by the same committee, but not in the same section as the updating expressions.
According to the W3C, updating expressions have the return type empty-sequence() and there are syntactical constraints that prohibit mixtures of updating and non-updating expressions.
Pathfinder, by contrast, knows an additional type, separate from any other type: statement (accessible via PFty_stmt() or something like that). Correctness of a query is then decided based on types. This should also be the right return type for fn:put().
The W3C specification even seems somewhat contradictory. According to static typing rules, most situations where an expression can statically be determined to yield the empty sequence are actually considered a type error. In consequence, there must not be a function whose return type is empty-sequence(). Pathfinder doesn't strictly implement this part of the static typing feature.
Best regards,
Jens
On Wed, Jul 9, 2008 at 9:41 AM, Sjoerd Mullender sjoerd@acm.org wrote:
empty-sequence() doesn't seem to be the right return type for fn:put(). Pathfinder decides the validity of updating expressions slightly different than the W3C specs (and, in my eyes, much more consistent).
The thing is, fn:put() is *not* an updating expression. It is defined in the same document by the same committee, but not in the same section as the updating expressions.
Hi Sjoerd,
I don't agree with this conclusion. fn:put() is defined in the same section (Section 2) as all the other update expressions. fn:put() has a side effect just as all the other update expressions.
There's an additional Section 3 that describes the underlying primitives that implement the ones from Section 2. But this is unrelated to the issue.
Jens
On Thu, Jul 10, 2008 at 09:36:03AM +0200, Jens Teubner wrote:
On Wed, Jul 9, 2008 at 9:41 AM, Sjoerd Mullender sjoerd@acm.org wrote:
empty-sequence() doesn't seem to be the right return type for fn:put(). Pathfinder decides the validity of updating expressions slightly different than the W3C specs (and, in my eyes, much more consistent).
The thing is, fn:put() is *not* an updating expression. It is defined in the same document by the same committee, but not in the same section as the updating expressions.
Hi Sjoerd,
I don't agree with this conclusion. fn:put() is defined in the same section (Section 2) as all the other update expressions. fn:put() has a side effect just as all the other update expressions.
Hi Jens,
Whether fn:put() is an updating function or not, is left quite open by XQUF. I think it's not wrong to define it as a non-updating function, given its current implementation in MXQ, since the side effect of fn:put() is completely different than the other update expressions and the pathfinder document management functions, namely, it only stores a document in the file system, but does not make any change to the database.
There's an additional Section 3 that describes the underlying primitives that implement the ones from Section 2. But this is unrelated to the issue.
As of http://www.w3.org/TR/2006/WD-xqupdate-20060711/, XQUF has removed the definition "... this function adds implementation-defined updates to the Pending Update List." Maybe another indication that it doesn't have to be an updating function?
Jennie
Jens
-- Jens Teubner, jens.teubner@gmail.com
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
Jens Teubner wrote:
On Wed, Jul 9, 2008 at 9:41 AM, Sjoerd Mullender sjoerd@acm.org wrote:
empty-sequence() doesn't seem to be the right return type for fn:put(). Pathfinder decides the validity of updating expressions slightly different than the W3C specs (and, in my eyes, much more consistent).
The thing is, fn:put() is *not* an updating expression. It is defined in the same document by the same committee, but not in the same section as the updating expressions.
Hi Sjoerd,
I don't agree with this conclusion. fn:put() is defined in the same section (Section 2) as all the other update expressions. fn:put() has a side effect just as all the other update expressions.
There's an additional Section 3 that describes the underlying primitives that implement the ones from Section 2. But this is unrelated to the issue.
Section 2 describes the extensions of the XQUF to XQuery 1.0. Section 2.6 describes the extensions to the built-in function library. There is one extension described there: fn:put(). Nowhere does it say there that this is an updating function. Read it.[1] You *cannot* conclude from the text there that fn:put() is an updating function, since if it were, it would say so there.
It may be that in older draft versions of XQUF fn:put() was defined as an updating function (although if it was, I can't find it, and I went back the list of Previous versions), but in the final recommendation it is not, and that is all that counts.
Apart from this, fn:put() also doesn't make sense as an updating function since it doesn't change anything in the document.
[1] http://www.w3.org/TR/xqupdate/#id-new-functions
On Tue, Jul 8, 2008 at 1:55 PM, Jens Teubner jens.teubner@gmail.com wrote:
On Tue, Jul 8, 2008 at 5:19 AM, Ying Zhang Y.Zhang@cwi.nl wrote:
You probably mean PFty_empty().
This might indeed be the type we are looking for, however, in the final generated MIL code, it contains no translation for fn:put() at all. The simplification/optimization steps didn't know that this "senseless" function has some side effect:)
I will try to find where fn:put has been simplified, or maybe Jan already has an idea?
Hi!
empty-sequence() doesn't seem to be the right return type for fn:put().
According to the spec, fn:put has return type empty-seq and it is *not* an update function: http://www.w3.org/TR/xquery-update-10/#id-func-put
they call it an extension to the built-in function library (!).
Pathfinder decides the validity of updating expressions slightly different than the W3C specs (and, in my eyes, much more consistent). According to the W3C, updating expressions have the return type empty-sequence() and there are syntactical constraints that prohibit mixtures of updating and non-updating expressions.
According to the (new?) w3c spec, in chapter 3 "Update operations", they say: "Although these update operations are described using a functional notation, they are not true functions because many of them have no return value." And also for each update function listed after they don't have a returning type.
I thing they have changed allot of stuff hence the confusion. I don't know what is the correct solution to this mix...
Pathfinder, by contrast, knows an additional type, separate from any other type: statement (accessible via PFty_stmt() or something like that). Correctness of a query is then decided based on types. This should also be the right return type for fn:put().
The W3C specification even seems somewhat contradictory. According to static typing rules, most situations where an expression can statically be determined to yield the empty sequence are actually considered a type error. In consequence, there must not be a function whose return type is empty-sequence(). Pathfinder doesn't strictly implement this part of the static typing feature.
Best regards,
Jens
-- Jens Teubner, jens.teubner@gmail.com
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On Wed, Jul 9, 2008 at 11:40 AM, Lefteris lsidir@gmail.com wrote:
According to the spec, fn:put has return type empty-seq and it is *not* an update function: http://www.w3.org/TR/xquery-update-10/#id-func-put
The Update Facility describes an empty return value for all the updating expressions. As I wrote earlier, Pathfinder does this a bit different (more consistent, in my opinion) and introduces a special type for update operations (you may also read this as "operations with a side effect", since this is what really matters here). And, as I responded to Sjoerd, I don't see how one can conclude from the specs that fn:put() is not an updating expression.
Jens
participants (6)
-
Jan Rittinger -
Jens Teubner -
Jens Teubner -
Lefteris -
Sjoerd Mullender -
Ying Zhang