So it is not expected behavior? Then I'll enter a bug report. Floris -----Original Message----- From: Lefteris [mailto:lsidir@gmail.com] Sent: donderdag 14 mei 2009 13:31 To: Communication channel for MonetDB users Subject: Re: [MonetDB-users] doc-available unuseable? This is a weird bug. if (0) then doc('asdasda') else element b{} will return <b/> while if (doc-available('asdasda')) then doc('lala') else element b{} will return the shred error. On Thu, May 14, 2009 at 12:43 PM, Floris Ouwendijk (DT) wrote:

Hi,

Given the following code, I'd assume to get an empty b element (for a database not containing the given document).

if (doc-available('asdasda')) then doc('asdasda') else element b{}

The result happens to be QUERY = if (doc-available('asdasda')) ERROR = !ERROR: [shred_url]: 1 times inserted nil due to errors at tuples 0@0.        !ERROR: [shred_url]: first error was:        !ERROR: shred: cannot stat `asdasda': No such file or directory        !ERROR: CMDshred_url: operation failed.        !ERROR: interpret_params: leftfetchjoin(param 2): evaluation error.

If I do if (doc-available('asdasda')) then  element a{} else element b{}

Then i get b.

What is the proper way to return some default value when a document is not available in the database? Or is this the proper way and should this be reported as a bug?

Kind regards,

Floris

---------------------------------------------------------------------- -------- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

Hi Floris, you and Sjoerd are correct that this error should never reach the surface. (That's also what the W3C says: http://www.w3.org/TR/xquery/#id-conditionals) . The problem here is that the error handling is done inside the call to fn:doc instead of modeling it in our algebra (where we have a notion of side effects that would provide the correct result). This error generation of fn:doc would be no problem if we would literally interpret the input query. The algebraic optimizations however is doing a quite thorough job detecting independent expressions and unnesting them. This leads to plans where all branches of an if-then- else expression can be evaluated in parallel (and in your example results in the error). Note that this also means that the independent expressions in both branches are always evaluated (even if they are discarded afterwards). Jan PS @ Floris: You can avoid your problem for now by introducing a artificial dependency as in the example secureDoc() function below to force the doc() call to inspect the result of doc-available(): declare function pf:secureDoc ($str as xs:string) as document-node()? { zero-or-one ( for $a in ($str, "::ThisDocDoesCertainlyNotExist::") return if (doc-available($str)) then doc($str) else() ) }; pf:secureDoc ("asdfasdf") On May 14, 2009, at 13:58, Sjoerd Mullender wrote:

I imagine this result happens due to the way conditionals are processed when doing bulk processing. Unless the conditional is constant (Lefteris' case), first both the "true" and "false" branches are calculated, and then one or the other is selected depending on the conditional.

But, please, report as bug.

Floris Ouwendijk (DT) wrote:

...

So it is not expected behavior? Then I'll enter a bug report.

Floris

-----Original Message----- From: Lefteris [mailto:lsidir@gmail.com] Sent: donderdag 14 mei 2009 13:31 To: Communication channel for MonetDB users Subject: Re: [MonetDB-users] doc-available unuseable?

This is a weird bug.

if (0) then doc('asdasda') else element b{}

will return <b/>

while

if (doc-available('asdasda')) then doc('lala') else element b{}

will return the shred error.

On Thu, May 14, 2009 at 12:43 PM, Floris Ouwendijk (DT)

...

wrote: Hi,

Given the following code, I'd assume to get an empty b element (for a database not containing the given document).

if (doc-available('asdasda')) then doc('asdasda') else element b{}

The result happens to be QUERY = if (doc-available('asdasda')) ERROR = !ERROR: [shred_url]: 1 times inserted nil due to errors at tuples 0@0. !ERROR: [shred_url]: first error was: !ERROR: shred: cannot stat `asdasda': No such file or directory !ERROR: CMDshred_url: operation failed. !ERROR: interpret_params: leftfetchjoin(param 2): evaluation error.

If I do if (doc-available('asdasda')) then element a{} else element b{}

Then i get b.

What is the proper way to return some default value when a document is not available in the database? Or is this the proper way and should this be reported as a bug?

Kind regards,

Floris

---------------------------------------------------------------------- -------- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

-- Sjoerd Mullender

------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com_______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

-- Jan Rittinger Lehrstuhl Datenbanken und Informationssysteme Wilhelm-Schickard-Institut für Informatik Eberhard-Karls-Universität Tübingen http://www-db.informatik.uni-tuebingen.de/team/rittinger