Hello Ricardo,

This is my fault, the feature may cause inadequate error diagnostics
depending on server building options and roll of dice. The attached diff
contain the fix, you may apply it to libsrc/Wi directory to not wait for
next release.

Best Regards,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com

On Thu, 2010-02-11 at 09:43 -0300, Ricardo Z wrote:
> Hi
> 
> We've installed installed virtuoso 6.1. One of the new features on the
> list is
> Added support for expressions in LIMIT and OFFSET clauses
> 
> So we tried to write again this query inside of a for in a virtuoso
> procedure.
> 
> sparql select distinct
> 
>     ?documentId ?title ?abstract ?title_relevance ?abstract_relevance 
> ?classification
>         {graph ?:hostUri {
>            ...
>            ...
>            ...
>         }} order by
>             desc((?title_relevance+?abstract_relevance)/2.0)
>             desc(?title_relevance/2.0)
>             desc(?abstract_relevance/2.0)
>         limit 50 offset ?:offsetValue
> 
> But we received this error message.
> "Unable to use variable ?:offsetValue in OPTION () clause, try to
> rephrase the query at"
> 
> which disappears when we replace ?:offsetValue by 0 or any integer.
> We use others procedure variable into "for (sparql query) do ..."
> sentence in the way we did for offset (?:<variable name>), in other
> contexts into the expresion and works fine.
> 
> We are referencing the variable wrong?
> 
> Thanks.
> Z.
> 
> 
> 
> 
> On Sun, Jan 24, 2010 at 11:55 AM, Aldo Bucchi <aldo.buc...@gmail.com>
> wrote:
>         Hi Ivan,
>         
>         On Thu, Jan 21, 2010 at 12:46 PM, Ivan Mikhailov
>         <imikhai...@openlinksw.com> wrote:
>         > Hello Aldo,
>         >
>         >> OK, and what about:
>         >> [10]* DefaultGraphClause       ::=  SourceSelector
>         SpongeOptionList?
>         >> [11]* NamedGraphClause         ::=  'NAMED' SourceSelector
>         SpongeOptionList?
>         >> ?
>         >
>         > That costs much more than an extension for LIMIT/OFFSET
>         (that is
>         > implemented already, right today). The reason is that any
>         extension in
>         > FROM/FROM NAMED interferes with graph-level security that is
>         complicated
>         > by itself and, more important, the debugging is complicated.
>         While
>         > other features should work when needed, security should
>         prevent things
>         > from working when unwanted; I'm an engineer, not a turnkey,
>         so that sort
>         > of thinking damage my brains in a quite unusual way :)
>         
>         
>         I see.
>         Now, there is always the option of implementing for the simple
>         subset
>         and then stating that this will bypass security, etc.
>         But that's a bigger problem I guess.
>         As an engineer, I also understand that when modifications
>         compromise
>         other (working) pieces of the system then they should be
>         queued at
>         least till there is a feature freeze.
>         Otherwise you might be shooting yourself on the foot.
>         
>         >
>         >> And, on a related note. The other low hanging fruit:
>         >> i++; i+=3
>         >
>         > That's a long-waiting feature, I'm going to add it since
>         2001. However the accurate implementation of the feature
>         should deal with UDT members as well, that requires some
>         amount of coding. A trivial "macroexpansion"
>         > like "i := i+1; i := i+3" does not work there, because
>         functions inside "i" will be calculated twice.
>         
>         
>         I could say that I understand ( because I do, in essence ),
>         but I
>         would be lying.
>         In concrete terms.. which specific case?
>         
>         declare person PersonUDT;
>         person := new PersonUDT();
>         
>         person.age++;
>         -- or
>         person.age += 1;
>         
>         -- would become
>         
>         person.age := person.age + 1;
>         
>         ??
>         
>         That's not the case I assume. But that's what I understand by
>         a UDT "member".
>         
>         Now, a UDT "instance" case would be
>         
>         person +:= person;
>         
>         (I'm not sure what the latter should mean anyway ).
>         
>         And also, remember that one very common use case beyond +:=
>         ( addition
>         ) is ||:= ( concatenation ).
>         
>         Regards,
>         A
>         
>         >
>         > Best Regards,
>         >
>         > Ivan Mikhailov
>         > OpenLink Software
>         > http://virtuoso.openlinksw.com
>         >
>         >
>         >
>         
>         
>         
>         
>         
>         --
>         Aldo Bucchi
>         skype:aldo.bucchi
>         http://www.univrz.com/
>         http://aldobucchi.com/
>         
>         PRIVILEGED AND CONFIDENTIAL INFORMATION
>         This message is only for the use of the individual or entity
>         to which it is
>         addressed and may contain information that is privileged and
>         confidential. If
>         you are not the intended recipient, please do not distribute
>         or copy this
>         communication, by e-mail or otherwise. Instead, please notify
>         us immediately by
>         return e-mail.
>         
> 
Index: sparql2sqltext.c
===================================================================
RCS file: /home/staff/us-cvs/virtuoso/libsrc/Wi/sparql2sqltext.c,v
retrieving revision 1.47.2.79
diff -u -U 10 -r1.47.2.79 sparql2sqltext.c
--- sparql2sqltext.c	8 Feb 2010 18:19:53 -0000	1.47.2.79
+++ sparql2sqltext.c	11 Feb 2010 13:01:32 -0000
@@ -3999,28 +3999,28 @@
 #if 0
         ssg_valmode_t vmode = sparp_expn_native_valmode (ssg->ssg_sparp, tree);
         if (vmode == needed)
           {
             sparp_equiv_t *eq = ssg->ssg_equivs[tree->_.var.equiv_idx];
             ssg_print_equiv_retval_expn (ssg, sparp_find_gp_by_alias (ssg->ssg_sparp, tree->_.var.selid), eq, 0, 1, needed, NULL_ASNAME);
           }
         else
           ssg_print_valmoded_scalar_expn (ssg, tree, needed, vmode);
 #else
+        if (SPART_VARNAME_IS_GLOB (tree->_.var.vname))
+          {
+            ssg_print_global_param (ssg, tree->_.var.vname, needed);
+            goto print_asname; /* see below */
+          }
         if (NULL == ssg->ssg_equivs) /* This is for case when parts of the SPARQL front-end are used to produce small SQL fragments */
           {
             ssg_valmode_t vmode;
-            if (SPART_VARNAME_IS_GLOB (tree->_.var.vname))
-              {
-                ssg_print_global_param (ssg, tree->_.retval.vname, needed);
-                goto print_asname; /* see below */
-              }
             vmode = sparp_expn_native_valmode (ssg->ssg_sparp, tree);
             if (vmode == needed)
               {
                 ssg_putchar (' ');
                 ssg_prin_id (ssg, tree->_.var.vname);
                 goto print_asname; /* see below */
               }
             ssg_print_valmoded_scalar_expn (ssg, tree, needed, vmode, asname);
           }
         else

Reply via email to