Hi Jan,

This reminds me of an open GitHub issue [1], but it’s just a guess.

Does your query work as expected if you append "update { }" to your
newly constructed element?

  let $new-element := element el {
     $sequence-of-elements } update { }

In BaseX, there are two different types of nodes: fragment nodes
(which are created by XQuery node constructors) and database nodes
(which are compact representations of XML trees). In your example, the
$sequence-of-elements (which, I guess, is a sequence of database
nodes) will be wrapped with an element constructor. By using "update
{}", your node will be copied and transformed to a database node. See
[2] for some more details on the update keyword.

Quite obviously this is just a workaround to test how your query
behaves. If it behaves correctly, I am pretty sure that [1] would need
to be fixed to get your query running correctly.

Cheers,
Christian

[1] https://github.com/BaseXdb/basex/issues/919
[2] http://docs.basex.org/wiki/Update#update


On Tue, Jun 20, 2017 at 8:09 PM, Jan Dölle <basex-l...@id1.de> wrote:
> Hi,
>
> just before you asking me. No we wasn't to isolate the Problem for now.
>
> Working on a complex transaction with database involved, we get the
> following phenomenon.
>
> declare function m:paths($el as element())
> as xs:string*
> {
>   distinct-values(
>     for $e in $item/descendant::*
>     return
>       string-join($e/ancestor-or-self::*/local-name(.), "/")
>   )
> };
>
> This function should produce a list of paths to all child of $el. And it
> works!
>
> But sometimes we get some strange results. We created new element
> constructed from others, may existing, elements.
>
> let $sequence-of-elements := collect-some-elements($from-somewhere)
> let $new-element := element el {  $sequence-of-elements }
> return paths($new-element)
>
> Most of the time we get as expected results like:
>
> el/c1
> el/c1/c12
> el/c2
> el/c2/c21
> el/c2/c22
> el/..
>
> But sometimes it looks like that parents of the copied elements are not set
> correctly:
>
> oldParentOfc1/c1
> oldParentOfc1/c1/c12
> otherOld/ParentOfc2/c2
> otherOld/ParentOfc2/c2/c21
> otherOld/ParentOfc2/c2/c22
> ...
>
> If we do a copy of the result <el> like parse-xml(serialize($new-element))/*
> and call paths() again, everything looks now as expected.
>
> We call the function what products such results, isolated within a
> test-script with exact the same inputs. But suddenly the result was correct.
>
> Then we copied the inputs of the function within the integration (parse-xml,
> serialize). But it failed again.
>
> Also notable is, that the "bad result" is stable. It produces always the
> same result on same inputs (no random).
>
> So we have no idea to isolate the issue.
>
> Any suggestions?
>
> Best Regards
>
> Jan
>
> --
>
> Jan Dölle
> E-Mail: basex-l...@id1.de Telefon +49-69-244502-0 Home: www.id1.de
>
> Information Design One AG, Baseler Straße 10, 60329 Frankfurt am Main
> Registereintrag: Amtsgericht Frankfurt am Main, HRB 52596
> Vorstand: Robert Peters, Aufsichtsrat: Christian Hecht (Vorsitz)
>
>

Reply via email to