"Expected type: element() got: node()" after index change

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

"Expected type: element() got: node()" after index change

Alexander Henket-2
Hi,

eXist-db-3.0.RC2-develop-005045f.dmg. I'm trying out RC3.0 to see if new range indexes are now stable compared to 2.2:

After updating the index definition from old range to new range, including combined indexes, I get this error on one of our existing functions:

<exception>
<path>/db/apps/art/modules/get-decor-dataset-tree.xquery</path>
<message>
err:XPTY0004 err:XPTY0004: return type of function 'art:getConcept'. exerr:ERROR Type error: expected type: element(); got: node() [at line 753, column 28] In function: art:getOriginalForConcept(element()?) [1507:66:/db/apps/art/modules/art-decor.xqm] art:conceptBasics(element()) [1398:23:/db/apps/art/modules/art-decor.xqm] art:getDatasetTree(xs:string?, xs:string?, xs:string?, xs:string?, xs:boolean) [28:8:/db/apps/art/modules/art-decor.xqm]
</message>
</exception>

Is this to be expected as a bug at this stage, or is my index definition not correct? The relevant part of the index definition is below. You could ask why I have @id/@effectiveDate listed separately and combined. This is because both occur on other nodes than dataset and concept as well and not necessarily in pair.

<!-- generic -->
<create qname="@id" type="xs:string"/>
<create qname="@effectiveDate" type="xs:string"/>

<!-- ... -->

<!-- combined indexes -->
<create qname="dataset">
   
<field name="dataset-id" match="@id" type="xs:string"/>
   
<field name="dataset-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>
<create qname="concept">
   
<field name="concept-id" match="@id" type="xs:string"/>
   
<field name="concept-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>
<create qname="inherit">
   
<field name="inherit-ref" match="@ref" type="xs:string"/>
   
<field name="inherit-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: "Expected type: element() got: node()" after index change

Alexander Henket-2
Just for reference: when I deactivate the combined index on concept (see below) the normal operation returns. So unless I misunderstood how the combined index should be configured, this appears to be a bug.

Alexander Henket

Op 27 okt. 2016, om 18:15 heeft Alexander Henket <[hidden email]> het volgende geschreven:

Hi,

eXist-db-3.0.RC2-develop-005045f.dmg. I'm trying out RC3.0 to see if new range indexes are now stable compared to 2.2:

After updating the index definition from old range to new range, including combined indexes, I get this error on one of our existing functions:

<exception>
<path>/db/apps/art/modules/get-decor-dataset-tree.xquery</path>
<message>
err:XPTY0004 err:XPTY0004: return type of function 'art:getConcept'. exerr:ERROR Type error: expected type: element(); got: node() [at line 753, column 28] In function: art:getOriginalForConcept(element()?) [1507:66:/db/apps/art/modules/art-decor.xqm] art:conceptBasics(element()) [1398:23:/db/apps/art/modules/art-decor.xqm] art:getDatasetTree(xs:string?, xs:string?, xs:string?, xs:string?, xs:boolean) [28:8:/db/apps/art/modules/art-decor.xqm]
</message>
</exception>

Is this to be expected as a bug at this stage, or is my index definition not correct? The relevant part of the index definition is below. You could ask why I have @id/@effectiveDate listed separately and combined. This is because both occur on other nodes than dataset and concept as well and not necessarily in pair.

<!-- generic -->
<create qname="@id" type="xs:string"/>
<create qname="@effectiveDate" type="xs:string"/>

<!-- ... -->

<!-- combined indexes -->
<create qname="dataset">
   
<field name="dataset-id" match="@id" type="xs:string"/>
   
<field name="dataset-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>
<create qname="concept">
   
<field name="concept-id" match="@id" type="xs:string"/>
   
<field name="concept-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>
<create qname="inherit">
   
<field name="inherit-ref" match="@ref" type="xs:string"/>
   
<field name="inherit-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: "Expected type: element() got: node()" after index change

Wolfgang Meier-2
Since the error message is about the return type of the function, could you show us the line which selects the return value in the function via the index?

Wolfgang



> Am 27.10.2016 um 20:35 schrieb Alexander Henket <[hidden email]>:
>
> Just for reference: when I deactivate the combined index on concept (see below) the normal operation returns. So unless I misunderstood how the combined index should be configured, this appears to be a bug.
>
> Alexander Henket
>
>> Op 27 okt. 2016, om 18:15 heeft Alexander Henket <[hidden email]> het volgende geschreven:
>>
>> Hi,
>>
>> eXist-db-3.0.RC2-develop-005045f.dmg. I'm trying out RC3.0 to see if new range indexes are now stable compared to 2.2:
>>
>> After updating the index definition from old range to new range, including combined indexes, I get this error on one of our existing functions:
>>
>> <exception>
>> <path>/db/apps/art/modules/get-decor-dataset-tree.xquery</path>
>> <message>
>> err:XPTY0004 err:XPTY0004: return type of function 'art:getConcept'. exerr:ERROR Type error: expected type: element(); got: node() [at line 753, column 28] In function: art:getOriginalForConcept(element()?) [1507:66:/db/apps/art/modules/art-decor.xqm] art:conceptBasics(element()) [1398:23:/db/apps/art/modules/art-decor.xqm] art:getDatasetTree(xs:string?, xs:string?, xs:string?, xs:string?, xs:boolean) [28:8:/db/apps/art/modules/art-decor.xqm]
>> </message>
>> </exception>
>>
>> Is this to be expected as a bug at this stage, or is my index definition not correct? The relevant part of the index definition is below. You could ask why I have @id/@effectiveDate listed separately and combined. This is because both occur on other nodes than dataset and concept as well and not necessarily in pair.
>>
>> <!-- generic -->
>> <create qname="@id" type="xs:string"/>
>> <create qname="@effectiveDate" type="xs:string"/>
>>
>> <!-- ... -->
>>
>> <!-- combined indexes -->
>> <create qname="dataset">
>>     <field name="dataset-id" match="@id" type="xs:string"/>
>>     <field name="dataset-effectiveDate" match="@effectiveDate" type="xs:string"/>
>> </create>
>> <create qname="concept">
>>     <field name="concept-id" match="@id" type="xs:string"/>
>>     <field name="concept-effectiveDate" match="@effectiveDate" type="xs:string"/>
>> </create>
>> <create qname="inherit">
>>     <field name="inherit-ref" match="@ref" type="xs:string"/>
>>     <field name="inherit-effectiveDate" match="@effectiveDate" type="xs:string"/>
>> </create>
>>
>> ------------------------------------------------------------------------------
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik_______________________________________________
>> Exist-open mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>
> ------------------------------------------------------------------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik_______________________________________________
> Exist-open mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/exist-open


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: "Expected type: element() got: node()" after index change

Alexander Henket-2
748 declare function art:getOriginalForConcept($concept as element(concept)?) as element(concept)? {
749     if ($concept[inherit]) then (
750         let $ref        := $concept/inherit/@ref
751         let $eff        := $concept/inherit/@effectiveDate
752        
753         let $concepts   := art:getConcept($ref, $eff, (), ())
754         return
755             art:getOriginalForConcept($concepts)
756     )
757     else
758     if ($concept[@ref]) then (
759         let $ref        := $concept/@ref
760         let $eff        := $concept/@flexibility
761        
762         let $concepts   := art:getConcept($ref, $eff, (), ())
763         return
764             art:getOriginalForConcept($concepts)
765     )
766     else (
767         $concept
768     )
769 };

and the function it calls at line 753 -- never mind the funky long speak. I've had to rewrite this function a zillion times to get it to perform as fast as I could rig it under eXist-db 2.2. eXist-2.2 does not perform on not() statements and does not perform on predicates with @effectiveDate for some reason.

declare function art:getConcept($de-id as xs:string, $de-ed as xs:string?, $decorVersion as xs:string?, $language as xs:string?) as element(concept)* {
    let $decor          :=
        if ($decorVersion[. castable as xs:dateTime]) then
            let $d      := $get:colDecorVersion/decor[@versionDate = $decorVersion]
            return
            if (empty($language)) then
                $d[@language=$d/project/@defaultLanguage]
            else if ($language='*') then
                $d
            else
                $d[@language=$language]
        else (
            $get:colDecorData
        )

    return
        if ($de-ed[. castable as xs:dateTime]) then
            $decor//concept[@id = $de-id][@effectiveDate = $de-ed][not(ancestor::history | ancestor::conceptList)][ancestor::datasets]
        else (
            let $concepts   := $decor//concept[@id = $de-id][not(ancestor::history | ancestor::conceptList)][ancestor::datasets]
           
            return
                if ($concepts[2]) then (
                    let $de-ed-max  := max($concepts/xs:dateTime(@effectiveDate))
                   
                    return $concepts[@effectiveDate = $de-ed-max]
                ) else (
                    $concepts
                )
        )
};


Op 27 okt. 2016, om 21:07 heeft Wolfgang Meier <[hidden email]> het volgende geschreven:

Since the error message is about the return type of the function, could you show us the line which selects the return value in the function via the index?

Wolfgang



Am 27.10.2016 um 20:35 schrieb Alexander Henket <[hidden email]>:

Just for reference: when I deactivate the combined index on concept (see below) the normal operation returns. So unless I misunderstood how the combined index should be configured, this appears to be a bug.

Alexander Henket

Op 27 okt. 2016, om 18:15 heeft Alexander Henket <[hidden email]> het volgende geschreven:

Hi,

eXist-db-3.0.RC2-develop-005045f.dmg. I'm trying out RC3.0 to see if new range indexes are now stable compared to 2.2:

After updating the index definition from old range to new range, including combined indexes, I get this error on one of our existing functions:

<exception>
<path>/db/apps/art/modules/get-decor-dataset-tree.xquery</path>
<message>
err:XPTY0004 err:XPTY0004: return type of function 'art:getConcept'. exerr:ERROR Type error: expected type: element(); got: node() [at line 753, column 28] In function: art:getOriginalForConcept(element()?) [1507:66:/db/apps/art/modules/art-decor.xqm] art:conceptBasics(element()) [1398:23:/db/apps/art/modules/art-decor.xqm] art:getDatasetTree(xs:string?, xs:string?, xs:string?, xs:string?, xs:boolean) [28:8:/db/apps/art/modules/art-decor.xqm]
</message>
</exception>

Is this to be expected as a bug at this stage, or is my index definition not correct? The relevant part of the index definition is below. You could ask why I have @id/@effectiveDate listed separately and combined. This is because both occur on other nodes than dataset and concept as well and not necessarily in pair.

<!-- generic -->
<create qname="@id" type="xs:string"/>
<create qname="@effectiveDate" type="xs:string"/>

<!-- ... -->

<!-- combined indexes -->
<create qname="dataset">
   <field name="dataset-id" match="@id" type="xs:string"/>
   <field name="dataset-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>
<create qname="concept">
   <field name="concept-id" match="@id" type="xs:string"/>
   <field name="concept-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>
<create qname="inherit">
   <field name="inherit-ref" match="@ref" type="xs:string"/>
   <field name="inherit-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open



------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|

Re: "Expected type: element() got: node()" after index change

Alexander Henket-2
I've tested some more:

- Combined indexes give me errors all over the place

- I've rewritten all group by statements from the previously supported and W3C compliant "group by $x := $y" to "let $x := $y   group by $x". This rules out another set of problems (see other post titled "New range?")

I'm currently testing with pure new range indexes, no combined indexes, and this seems to go well. My previous experience was mixed as soon as I start writing in new range indexed collections. I did not get to that point yet.

Regards

Alexander Henket


Op 27 okt. 2016, om 21:19 heeft Alexander Henket <[hidden email]> het volgende geschreven:

748 declare function art:getOriginalForConcept($concept as element(concept)?) as element(concept)? {
749     if ($concept[inherit]) then (
750         let $ref        := $concept/inherit/@ref
751         let $eff        := $concept/inherit/@effectiveDate
752        
753         let $concepts   := art:getConcept($ref, $eff, (), ())
754         return
755             art:getOriginalForConcept($concepts)
756     )
757     else
758     if ($concept[@ref]) then (
759         let $ref        := $concept/@ref
760         let $eff        := $concept/@flexibility
761        
762         let $concepts   := art:getConcept($ref, $eff, (), ())
763         return
764             art:getOriginalForConcept($concepts)
765     )
766     else (
767         $concept
768     )
769 };

and the function it calls at line 753 -- never mind the funky long speak. I've had to rewrite this function a zillion times to get it to perform as fast as I could rig it under eXist-db 2.2. eXist-2.2 does not perform on not() statements and does not perform on predicates with @effectiveDate for some reason.

declare function art:getConcept($de-id as xs:string, $de-ed as xs:string?, $decorVersion as xs:string?, $language as xs:string?) as element(concept)* {
    let $decor          :=
        if ($decorVersion[. castable as xs:dateTime]) then
            let $d      := $get:colDecorVersion/decor[@versionDate = $decorVersion]
            return
            if (empty($language)) then
                $d[@language=$d/project/@defaultLanguage]
            else if ($language='*') then
                $d
            else
                $d[@language=$language]
        else (
            $get:colDecorData
        )

    return
        if ($de-ed[. castable as xs:dateTime]) then
            $decor//concept[@id = $de-id][@effectiveDate = $de-ed][not(ancestor::history | ancestor::conceptList)][ancestor::datasets]
        else (
            let $concepts   := $decor//concept[@id = $de-id][not(ancestor::history | ancestor::conceptList)][ancestor::datasets]
           
            return
                if ($concepts[2]) then (
                    let $de-ed-max  := max($concepts/xs:dateTime(@effectiveDate))
                   
                    return $concepts[@effectiveDate = $de-ed-max]
                ) else (
                    $concepts
                )
        )
};


Op 27 okt. 2016, om 21:07 heeft Wolfgang Meier <[hidden email]> het volgende geschreven:

Since the error message is about the return type of the function, could you show us the line which selects the return value in the function via the index?

Wolfgang



Am 27.10.2016 um 20:35 schrieb Alexander Henket <[hidden email]>:

Just for reference: when I deactivate the combined index on concept (see below) the normal operation returns. So unless I misunderstood how the combined index should be configured, this appears to be a bug.

Alexander Henket

Op 27 okt. 2016, om 18:15 heeft Alexander Henket <[hidden email]> het volgende geschreven:

Hi,

eXist-db-3.0.RC2-develop-005045f.dmg. I'm trying out RC3.0 to see if new range indexes are now stable compared to 2.2:

After updating the index definition from old range to new range, including combined indexes, I get this error on one of our existing functions:

<exception>
<path>/db/apps/art/modules/get-decor-dataset-tree.xquery</path>
<message>
err:XPTY0004 err:XPTY0004: return type of function 'art:getConcept'. exerr:ERROR Type error: expected type: element(); got: node() [at line 753, column 28] In function: art:getOriginalForConcept(element()?) [1507:66:/db/apps/art/modules/art-decor.xqm] art:conceptBasics(element()) [1398:23:/db/apps/art/modules/art-decor.xqm] art:getDatasetTree(xs:string?, xs:string?, xs:string?, xs:string?, xs:boolean) [28:8:/db/apps/art/modules/art-decor.xqm]
</message>
</exception>

Is this to be expected as a bug at this stage, or is my index definition not correct? The relevant part of the index definition is below. You could ask why I have @id/@effectiveDate listed separately and combined. This is because both occur on other nodes than dataset and concept as well and not necessarily in pair.

<!-- generic -->
<create qname="@id" type="xs:string"/>
<create qname="@effectiveDate" type="xs:string"/>

<!-- ... -->

<!-- combined indexes -->
<create qname="dataset">
   <field name="dataset-id" match="@id" type="xs:string"/>
   <field name="dataset-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>
<create qname="concept">
   <field name="concept-id" match="@id" type="xs:string"/>
   <field name="concept-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>
<create qname="inherit">
   <field name="inherit-ref" match="@ref" type="xs:string"/>
   <field name="inherit-effectiveDate" match="@effectiveDate" type="xs:string"/>
</create>

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open


------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open