Change in import behavior

On Mon, Jul 13, 2026 at 11:35 AM Marco Lettere via BaseX-Talk <basex-talk at mailman.uni-konstanz.de> wrote: > > Dear all, > > I've noticed moving from 11.9 to 12.3 that one import statement got lost and was no longer able to find corresponding module. > > I noticed that the way the file is placed in the repo has changed and it seems as if dots now separate content into subfolders. Thus test:v1.0.0 becomes test/v1/0/0/0.xqm. > > The problem is that it somehow fails to resolve. > > I could reproduce by having this module repo install(ed): > > module namespace _ = "test:v1.0.0"; > declare variable $_:A := 1; > > it is now placed into repo/test/v1/0/0.xqm whereas I'm pretty sure it was placed in repo/test/v1.0.0.xqm before. > > And then refer to it with: > > import module namespace _ = "test:v1.0.0"; > > It statically fails with: "Module not found test:v1.0.0". > > I can try to rename but using semver tags is something rather frequent so I'd like to know what underlies the issue. > > Thank you. > > Marco.

On 7/13/26 16:07, Bridger Dyson-Smith wrote: > Hi Marco - > > I wonder if there's been a change to more closely align with the > packaging specs? I have a small library with the semver info kept in > the expath-pkg.xml. This package, when bumped, keeps both versions in > the repo directory; e.g. > bridger@catwalker|~/bin/basex/repo > ) ls > http-canofbees.org-ns-xq-xpath-utils-0.0.2 > http-canofbees.org-ns-xq-xpath-utils-0.0.3 > http-www.functx.com-1.0 > https-doi.org-10.5281-zenodo.1495494-1.10.1 > test > > I know this doesn't answer your question directly, but maybe this is > an option for working around the issue. > > Best, > Bridger > > PS I probably need to explore moving this from ant to gradle or some > other build process, but I'm happy to share what I'm using if it would > be helpful. > > On Mon, Jul 13, 2026 at 11:35 AM Marco Lettere via BaseX-Talk > <basex-talk at mailman.uni-konstanz.de> wrote: >> Dear all, >> >> I've noticed moving from 11.9 to 12.3 that one import statement got lost and was no longer able to find corresponding module. >> >> I noticed that the way the file is placed in the repo has changed and it seems as if dots now separate content into subfolders. Thus test:v1.0.0 becomes test/v1/0/0/0.xqm. >> >> The problem is that it somehow fails to resolve. >> >> I could reproduce by having this module repo install(ed): >> >> module namespace _ = "test:v1.0.0"; >> declare variable $_:A := 1; >> >> it is now placed into repo/test/v1/0/0.xqm whereas I'm pretty sure it was placed in repo/test/v1.0.0.xqm before. >> >> And then refer to it with: >> >> import module namespace _ = "test:v1.0.0"; >> >> It statically fails with: "Module not found test:v1.0.0". >> >> I can try to rename but using semver tags is something rather frequent so I'd like to know what underlies the issue. >> >> Thank you. >> >> Marco.

On Mon, Jul 13, 2026 at 2:17 PM Marco Lettere <m.lettere at gmail.com> wrote: > > Thanks Bridger, > > just to be more precise we have a naming convention for our module that is based on URNs. > > So all modules are named like urn:some:domain:functionality. All those work as they did pre 12.x so we never encountered the issue in the last few monts. > > In few very rare cases we have urn:some:domain:functionality:vse.mv.er and this is the only case where it happens. So there must be some slight inconsistency that makes the case fail even if it seems to be working smoothly with modules that have URLs instead. > > We could maybe change the semver to use - instead of . but we cannot move away from URNs that would be too impactful. I just would like to know if it is a feature or a bug to take a decision about how to fix it. > > Thanks! > > M. > > On 7/13/26 16:07, Bridger Dyson-Smith wrote: > > Hi Marco - > > I wonder if there's been a change to more closely align with the > packaging specs? I have a small library with the semver info kept in > the expath-pkg.xml. This package, when bumped, keeps both versions in > the repo directory; e.g. > bridger@catwalker|~/bin/basex/repo > ) ls > http-canofbees.org-ns-xq-xpath-utils-0.0.2 > http-canofbees.org-ns-xq-xpath-utils-0.0.3 > http-www.functx.com-1.0 > https-doi.org-10.5281-zenodo.1495494-1.10.1 > test > > I know this doesn't answer your question directly, but maybe this is > an option for working around the issue. > > Best, > Bridger > > PS I probably need to explore moving this from ant to gradle or some > other build process, but I'm happy to share what I'm using if it would > be helpful. > > On Mon, Jul 13, 2026 at 11:35 AM Marco Lettere via BaseX-Talk > <basex-talk at mailman.uni-konstanz.de> wrote: > > Dear all, > > I've noticed moving from 11.9 to 12.3 that one import statement got lost and was no longer able to find corresponding module. > > I noticed that the way the file is placed in the repo has changed and it seems as if dots now separate content into subfolders. Thus test:v1.0.0 becomes test/v1/0/0/0.xqm. > > The problem is that it somehow fails to resolve. > > I could reproduce by having this module repo install(ed): > > module namespace _ = "test:v1.0.0"; > declare variable $_:A := 1; > > it is now placed into repo/test/v1/0/0.xqm whereas I'm pretty sure it was placed in repo/test/v1.0.0.xqm before. > > And then refer to it with: > > import module namespace _ = "test:v1.0.0"; > > It statically fails with: "Module not found test:v1.0.0". > > I can try to rename but using semver tags is something rather frequent so I'd like to know what underlies the issue. > > Thank you. > > Marco.

>And now I'm wondering if there's a way to import a module at a specific

On Mon, 13 Jul 2026 at 15:30, Bridger Dyson-Smith via BaseX-Talk < basex-talk at mailman.uni-konstanz.de> wrote: > Marco, > > I think I understand. I started to think that I hadn't fully > appreciated your problem and you've definitely confirmed that. > Hopefully Christian and co will be able to speak to the problem > quickly. > Thanks for clarifying! > > Best, > Bridger > > And now I'm wondering if there's a way to import a module at a > specific version point aside from using the `at` syntax. > `import module namespace cob = "http://canofbees.org/ns/xq/thing" at > "/path/to/specific/version.xqm"` seems unwieldy. > > On Mon, Jul 13, 2026 at 2:17 PM Marco Lettere <m.lettere at gmail.com> wrote: > > > > Thanks Bridger, > > > > just to be more precise we have a naming convention for our module that > is based on URNs. > > > > So all modules are named like urn:some:domain:functionality. All those > work as they did pre 12.x so we never encountered the issue in the last few > monts. > > > > In few very rare cases we have urn:some:domain:functionality:vse.mv.er > and this is the only case where it happens. So there must be some slight > inconsistency that makes the case fail even if it seems to be working > smoothly with modules that have URLs instead. > > > > We could maybe change the semver to use - instead of . but we cannot > move away from URNs that would be too impactful. I just would like to know > if it is a feature or a bug to take a decision about how to fix it. > > > > Thanks! > > > > M. > > > > On 7/13/26 16:07, Bridger Dyson-Smith wrote: > > > > Hi Marco - > > > > I wonder if there's been a change to more closely align with the > > packaging specs? I have a small library with the semver info kept in > > the expath-pkg.xml. This package, when bumped, keeps both versions in > > the repo directory; e.g. > > bridger@catwalker|~/bin/basex/repo > > ) ls > > http-canofbees.org-ns-xq-xpath-utils-0.0.2 > > http-canofbees.org-ns-xq-xpath-utils-0.0.3 > > http-www.functx.com-1.0 > > https-doi.org-10.5281-zenodo.1495494-1.10.1 > > test > > > > I know this doesn't answer your question directly, but maybe this is > > an option for working around the issue. > > > > Best, > > Bridger > > > > PS I probably need to explore moving this from ant to gradle or some > > other build process, but I'm happy to share what I'm using if it would > > be helpful. > > > > On Mon, Jul 13, 2026 at 11:35 AM Marco Lettere via BaseX-Talk > > <basex-talk at mailman.uni-konstanz.de> wrote: > > > > Dear all, > > > > I've noticed moving from 11.9 to 12.3 that one import statement got lost > and was no longer able to find corresponding module. > > > > I noticed that the way the file is placed in the repo has changed and it > seems as if dots now separate content into subfolders. Thus test:v1.0.0 > becomes test/v1/0/0/0.xqm. > > > > The problem is that it somehow fails to resolve. > > > > I could reproduce by having this module repo install(ed): > > > > module namespace _ = "test:v1.0.0"; > > declare variable $_:A := 1; > > > > it is now placed into repo/test/v1/0/0.xqm whereas I'm pretty sure it > was placed in repo/test/v1.0.0.xqm before. > > > > And then refer to it with: > > > > import module namespace _ = "test:v1.0.0"; > > > > It statically fails with: "Module not found test:v1.0.0". > > > > I can try to rename but using semver tags is something rather frequent > so I'd like to know what underlies the issue. > > > > Thank you. > > > > Marco. >

On 7/13/2026 1:35 PM, Marco Lettere via BaseX-Talk wrote: > Dear all, > > I've noticed moving from 11.9 to 12.3 that one import statement got lost > and was no longer able to find corresponding module. > > I noticed that the way the file is placed in the repo has changed and it > seems as if dots now separate content into subfolders. Thus test:v1.0.0 > becomes test/v1/0/0/0.xqm. > > The problem is that it somehow fails to resolve. > > I could reproduce by having this module /repo install/(ed): > > module namespace _ = "test:v1.0.0"; > declare variable $_:A := 1; > > it is now placed into *repo/test/v1/0/0.xqm* whereas I'm pretty sure it > was placed in* repo/test/v1.0.0.xqm* before. > > And then refer to it with: > > import module namespace _ = "test:v1.0.0"; > > It statically fails with: "Module not found test:v1.0.0". > > I can try to rename but using semver tags is something rather frequent > so I'd like to know what underlies the issue. > > Thank you. > > Marco. >

On 7/15/26 09:29, Gunther Rademacher wrote: > Hello Marco, > > thank you for reporting this. It is an unwanted side effect of the > changes that were made for PR 2566 [1], which went into BaseX 12.1. > > It has been handled by PR 2720 [2], and the fix is now available in > the latest snapshot [3]. > > Note that a module already installed under the old incorrect path > should be reinstalled to pick up the corrected location. The reinstall > restores resolution, but the previously misplaced file (e.g. > test/v1/0/0.xqm) is left behind. It can be left there with no harm, > but it can also be removed manually if you want a clean repository. > > Best regards, > Gunther > > [1] https://github.com/BaseXdb/basex/pull/2566 > [2] https://github.com/BaseXdb/basex/pull/2720 > [3] https://files.basex.org/releases/latest/ > > > On 7/13/2026 1:35 PM, Marco Lettere via BaseX-Talk wrote: >> Dear all, >> >> I've noticed moving from 11.9 to 12.3 that one import statement got >> lost and was no longer able to find corresponding module. >> >> I noticed that the way the file is placed in the repo has changed and >> it seems as if dots now separate content into subfolders. Thus >> test:v1.0.0 becomes test/v1/0/0/0.xqm. >> >> The problem is that it somehow fails to resolve. >> >> I could reproduce by having this module /repo install/(ed): >> >> module namespace _ = "test:v1.0.0"; >> declare variable $_:A := 1; >> >> it is now placed into *repo/test/v1/0/0.xqm* whereas I'm pretty sure >> it was placed in* repo/test/v1.0.0.xqm* before. >> >> And then refer to it with: >> >> import module namespace _ = "test:v1.0.0"; >> >> It statically fails with: "Module not found test:v1.0.0". >> >> I can try to rename but using semver tags is something rather >> frequent so I'd like to know what underlies the issue. >> >> Thank you. >> >> Marco. >> >

> XQUERY client:query(client:connect("localhost", 1984, "admin",

> XQUERY client:query(client:connect("localhost", 1984, "admin",

> XQUERY client:query(client:connect("repository", 1984, "admin",

On 7/15/26 09:29, Gunther Rademacher wrote: > Hello Marco, > > thank you for reporting this. It is an unwanted side effect of the > changes that were made for PR 2566 [1], which went into BaseX 12.1. > > It has been handled by PR 2720 [2], and the fix is now available in > the latest snapshot [3]. > > Note that a module already installed under the old incorrect path > should be reinstalled to pick up the corrected location. The reinstall > restores resolution, but the previously misplaced file (e.g. > test/v1/0/0.xqm) is left behind. It can be left there with no harm, > but it can also be removed manually if you want a clean repository. > > Best regards, > Gunther > > [1] https://github.com/BaseXdb/basex/pull/2566 > [2] https://github.com/BaseXdb/basex/pull/2720 > [3] https://files.basex.org/releases/latest/ > > > On 7/13/2026 1:35 PM, Marco Lettere via BaseX-Talk wrote: >> Dear all, >> >> I've noticed moving from 11.9 to 12.3 that one import statement got >> lost and was no longer able to find corresponding module. >> >> I noticed that the way the file is placed in the repo has changed and >> it seems as if dots now separate content into subfolders. Thus >> test:v1.0.0 becomes test/v1/0/0/0.xqm. >> >> The problem is that it somehow fails to resolve. >> >> I could reproduce by having this module /repo install/(ed): >> >> module namespace _ = "test:v1.0.0"; >> declare variable $_:A := 1; >> >> it is now placed into *repo/test/v1/0/0.xqm* whereas I'm pretty sure >> it was placed in* repo/test/v1.0.0.xqm* before. >> >> And then refer to it with: >> >> import module namespace _ = "test:v1.0.0"; >> >> It statically fails with: "Module not found test:v1.0.0". >> >> I can try to rename but using semver tags is something rather >> frequent so I'd like to know what underlies the issue. >> >> Thank you. >> >> Marco. >> >

Von: Marco Lettere via BaseX-Talk <basex-talk at mailman.uni-konstanz.de> Gesendet: Donnerstag, 16. Juli 2026 11:05 An: Gunther Rademacher; basex-talk at mailman.uni-konstanz.de Betreff: [basex-talk] Incompatibility between 12.4 and 11.7 Dear all, I've left the mail related the import issue we had few days ago as reference because the new issue relates somehow. We have two basex instances one that acts as a repository and one that acts as orchestrator publishing REST services and connecting to the repository through the client:connect, client:query, client:close APIs. We had to leave the repository on 11.7 because in 12.4 we have the problem with importing modules with semver and dots. We cannot move it to the patched version because that one is already on the 13 route which removes MIXUPDATES causing the de facto invalidation of our ten years old codebase which heavily relies on this option and it will just cost too much effort for us to refactor everything. So we moved only the orchestrator to 12.4 but now we have an issue because we cannot access resources that are stored in databases as documents. We enter the container that runs repository and do (suppose testdb already exists): BaseX 11.7 [Standalone] > XQUERY client:query(client:connect("localhost", 1984, "admin", "..."), "db:put-value('testdb', document{<doc/>}, 'test')") Query "basex" executed in 7.0 ms. > XQUERY client:query(client:connect("localhost", 1984, "admin", "..."), "db:get-value('testdb', 'test')") <doc/> Query "basex" executed in 14.5 ms. Fine. I can access the document also from dba. Then I enter the container that runs orchestrator with 12.4 and do: BaseX 12.4 [Standalone] > XQUERY client:query(client:connect("repository", 1984, "admin", "..."), "db:get-value('testdb', 'test')") Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk at mailman.uni-konstanz.de<mailto:basex-talk at mailman.uni-konstanz.de> Version: BaseX 12.4 Java: Alpine, 17.0.12 OS: Linux, amd64 Stack Trace: java.lang.NullPointerException: Cannot invoke "org.basex.query.value.type.Type.id()" because the return value of "org.basex.query.value.type.Types.type(int)" is null at org.basex.api.client.Query.cache(Query.java:125) at org.basex.api.client.ClientQuery.cache(ClientQuery.java:117) at org.basex.query.func.client.ClientQuery.value(ClientQuery.java:40) at org.basex.query.expr.ParseExpr.iter(ParseExpr.java:66) at org.basex.query.scope.MainModule.iter(MainModule.java:53) at org.basex.query.QueryContext.lambda$iter$4(QueryContext.java:392) at org.basex.query.QueryContext.run(QueryContext.java:792) at org.basex.query.QueryContext.iter(QueryContext.java:392) at org.basex.query.QueryProcessor.iter(QueryProcessor.java:98) at org.basex.core.cmd.AQuery.run(AQuery.java:89) at org.basex.core.Command.run(Command.java:233) at org.basex.core.Command.execute(Command.java:93) at org.basex.api.client.LocalSession.execute(LocalSession.java:131) at org.basex.api.client.Session.execute(Session.java:36) at org.basex.core.CLI.execute(CLI.java:98) at org.basex.core.CLI.execute(CLI.java:81) at org.basex.BaseX.console(BaseX.java:188) at org.basex.BaseX.<init>(BaseX.java:163) at org.basex.BaseX.main(BaseX.java:44) Query "basex" executed in 26.07 ms. This happens only when data is stored as document. If I store the xml without document wrapper it works as expected. Is there an actual incompatibility between the two versions or is this a bug? Thanks and sorry for being verbose but I feel like it's important to document that removal of something like MIXUPDATES can cause a notable butterfly effect and it should probably be balloted or somehow anticipated. Marco. On 7/15/26 09:29, Gunther Rademacher wrote: Hello Marco, thank you for reporting this. It is an unwanted side effect of the changes that were made for PR 2566 [1], which went into BaseX 12.1. It has been handled by PR 2720 [2], and the fix is now available in the latest snapshot [3]. Note that a module already installed under the old incorrect path should be reinstalled to pick up the corrected location. The reinstall restores resolution, but the previously misplaced file (e.g. test/v1/0/0.xqm) is left behind. It can be left there with no harm, but it can also be removed manually if you want a clean repository. Best regards, Gunther [1] https://github.com/BaseXdb/basex/pull/2566 [2] https://github.com/BaseXdb/basex/pull/2720 [3] https://files.basex.org/releases/latest/ On 7/13/2026 1:35 PM, Marco Lettere via BaseX-Talk wrote: Dear all, I've noticed moving from 11.9 to 12.3 that one import statement got lost and was no longer able to find corresponding module. I noticed that the way the file is placed in the repo has changed and it seems as if dots now separate content into subfolders. Thus test:v1.0.0 becomes test/v1/0/0/0.xqm. The problem is that it somehow fails to resolve. I could reproduce by having this module /repo install/(ed): module namespace _ = "test:v1.0.0"; declare variable $_:A := 1; it is now placed into *repo/test/v1/0/0.xqm* whereas I'm pretty sure it was placed in* repo/test/v1.0.0.xqm* before. And then refer to it with: import module namespace _ = "test:v1.0.0"; It statically fails with: "Module not found test:v1.0.0". I can try to rename but using semver tags is something rather frequent so I'd like to know what underlies the issue. Thank you. Marco.

On 7/16/26 11:54, Christian Grün wrote: > Hi Marco, > > Sorry for the unexpected changes that will surface with BaseX 13, which include removal of server-side web forwarding (web:forward) and, as you noticed, the mixture of updates and results via MIXUPDATES. The option was not used in any client projects that we are, or have been, involved in in recent years. Its semantics needed to be thought through for every extension of XQuery 4.0, and it was all proprietary work, as there will be no version 4 of W3 XQuery Update Facility. > > Due to our limited Open-Source resources, we need to focus on the development our latest releases. However, we do produce backports for older versions of BaseX for contracted clients. We could think about doing this for specific bug of version 12 as well. > > The bug you have encountered is certainly something we should understand. Can you reproduce it with the current 13 branch? If yes, could you possibly provide us with a self-contained example? > > All the best, > Christian > ________________________________________ > > Von: Marco Lettere via BaseX-Talk<basex-talk at mailman.uni-konstanz.de> > Gesendet: Donnerstag, 16. Juli 2026 11:05 > An: Gunther Rademacher;basex-talk at mailman.uni-konstanz.de > Betreff: [basex-talk] Incompatibility between 12.4 and 11.7 > > Dear all, > > I've left the mail related the import issue we had few days ago as reference because the new issue relates somehow. > > We have two basex instances one that acts as a repository and one that acts as orchestrator publishing REST services and connecting to the repository through the client:connect, client:query, client:close APIs. > > We had to leave the repository on 11.7 because in 12.4 we have the problem with importing modules with semver and dots. We cannot move it to the patched version because that one is already on the 13 route which removes MIXUPDATES causing the de facto invalidation of our ten years old codebase which heavily relies on this option and it will just cost too much effort for us to refactor everything. > > So we moved only the orchestrator to 12.4 but now we have an issue because we cannot access resources that are stored in databases as documents. > > We enter the container that runs repository and do (suppose testdb already exists): > > BaseX 11.7 [Standalone] > >> XQUERY client:query(client:connect("localhost", 1984, "admin", "..."), "db:put-value('testdb', document{<doc/>}, 'test')") > Query "basex" executed in 7.0 ms. > >> XQUERY client:query(client:connect("localhost", 1984, "admin", "..."), "db:get-value('testdb', 'test')") > <doc/> > Query "basex" executed in 14.5 ms. > > Fine. I can access the document also from dba. Then I enter the container that runs orchestrator with 12.4 and do: > > BaseX 12.4 [Standalone] > >> XQUERY client:query(client:connect("repository", 1984, "admin", "..."), "db:get-value('testdb', 'test')") > Improper use? Potential bug? Your feedback is welcome: > Contact:basex-talk at mailman.uni-konstanz.de<mailto:basex-talk at mailman.uni-konstanz.de> > Version: BaseX 12.4 > Java: Alpine, 17.0.12 > OS: Linux, amd64 > Stack Trace: > java.lang.NullPointerException: Cannot invoke "org.basex.query.value.type.Type.id()" because the return value of "org.basex.query.value.type.Types.type(int)" is null > at org.basex.api.client.Query.cache(Query.java:125) > at org.basex.api.client.ClientQuery.cache(ClientQuery.java:117) > at org.basex.query.func.client.ClientQuery.value(ClientQuery.java:40) > at org.basex.query.expr.ParseExpr.iter(ParseExpr.java:66) > at org.basex.query.scope.MainModule.iter(MainModule.java:53) > at org.basex.query.QueryContext.lambda$iter$4(QueryContext.java:392) > at org.basex.query.QueryContext.run(QueryContext.java:792) > at org.basex.query.QueryContext.iter(QueryContext.java:392) > at org.basex.query.QueryProcessor.iter(QueryProcessor.java:98) > at org.basex.core.cmd.AQuery.run(AQuery.java:89) > at org.basex.core.Command.run(Command.java:233) > at org.basex.core.Command.execute(Command.java:93) > at org.basex.api.client.LocalSession.execute(LocalSession.java:131) > at org.basex.api.client.Session.execute(Session.java:36) > at org.basex.core.CLI.execute(CLI.java:98) > at org.basex.core.CLI.execute(CLI.java:81) > at org.basex.BaseX.console(BaseX.java:188) > at org.basex.BaseX.<init>(BaseX.java:163) > at org.basex.BaseX.main(BaseX.java:44) > > Query "basex" executed in 26.07 ms. > > This happens only when data is stored as document. If I store the xml without document wrapper it works as expected. > > Is there an actual incompatibility between the two versions or is this a bug? > > Thanks and sorry for being verbose but I feel like it's important to document that removal of something like MIXUPDATES can cause a notable butterfly effect and it should probably be balloted or somehow anticipated. > > Marco. > > On 7/15/26 09:29, Gunther Rademacher wrote: > Hello Marco, > > thank you for reporting this. It is an unwanted side effect of the changes that were made for PR 2566 [1], which went into BaseX 12.1. > > It has been handled by PR 2720 [2], and the fix is now available in the latest snapshot [3]. > > Note that a module already installed under the old incorrect path should be reinstalled to pick up the corrected location. The reinstall restores resolution, but the previously misplaced file (e.g. test/v1/0/0.xqm) is left behind. It can be left there with no harm, but it can also be removed manually if you want a clean repository. > > Best regards, > Gunther > > [1]https://github.com/BaseXdb/basex/pull/2566 > [2]https://github.com/BaseXdb/basex/pull/2720 > [3]https://files.basex.org/releases/latest/ > > > On 7/13/2026 1:35 PM, Marco Lettere via BaseX-Talk wrote: > Dear all, > > I've noticed moving from 11.9 to 12.3 that one import statement got lost and was no longer able to find corresponding module. > > I noticed that the way the file is placed in the repo has changed and it seems as if dots now separate content into subfolders. Thus test:v1.0.0 becomes test/v1/0/0/0.xqm. > > The problem is that it somehow fails to resolve. > > I could reproduce by having this module /repo install/(ed): > > module namespace _ = "test:v1.0.0"; > declare variable $_:A := 1; > > it is now placed into *repo/test/v1/0/0.xqm* whereas I'm pretty sure it was placed in* repo/test/v1.0.0.xqm* before. > > And then refer to it with: > > import module namespace _ = "test:v1.0.0"; > > It statically fails with: "Module not found test:v1.0.0". > > I can try to rename but using semver tags is something rather frequent so I'd like to know what underlies the issue. > > Thank you. > > Marco.

Marco Lettere <m.lettere at gmail.com> schrieb am Freitag, 18. September 2026 um 13:42: > Hello, > > I've again issues making two different versions of BaseX communicate with each other through the native protocol. > > The exception is in ClientSession and it looks as if the params are not formatted correctly. > > I have a latest (20th August) that tries to query a 12.4... > > Any hint? Is this expected that protocol breaks among different versions? > > M. > > [1] > > Unexpected error: Improper use? Potential bug? Your feedback is welcome: > Contact: basex-talk at mailman.uni-konstanz.de > Version: BaseX 13.0 beta 39fb161 > Java: Alpine, 21.0.12 > OS: Linux, amd64 > Stack Trace: > java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 > at org.basex.api.client.ClientSession.<init>(ClientSession.java:116) > at org.basex.api.client.ClientSession.<init>(ClientSession.java:76) > at org.basex.query.func.client.ClientConnect.item(ClientConnect.java:25) > at org.basex.query.func.client.ClientConnect.item(ClientConnect.java:17) > at org.basex.query.expr.ParseExpr.value(ParseExpr.java:71) > at org.basex.query.expr.Pipeline.eval(Pipeline.java:96) > at org.basex.query.expr.Pipeline.value(Pipeline.java:81) > at org.basex.query.expr.gflwor.GFLWOR.value(GFLWOR.java:124) > at org.basex.query.expr.Switch.value(Switch.java:208) > at org.basex.query.expr.gflwor.Let$LetEval.next(Let.java:147) > at org.basex.query.expr.gflwor.GFLWOR.value(GFLWOR.java:124) > at org.basex.query.func.StaticFunc.invokeInternal(StaticFunc.java:175) > at org.basex.query.func.XQFunction.invoke(XQFunction.java:33) > at org.basex.query.func.FuncCall.evalFunc(FuncCall.java:41) > at org.basex.query.func.StaticFuncCall.value(StaticFuncCall.java:121) > at org.basex.query.expr.ParseExpr.iter(ParseExpr.java:66) > at org.basex.query.expr.List$1.iter(List.java:203) > at org.basex.query.expr.List$1.next(List.java:171) > at org.basex.query.func.fn.FnStringJoin.item(FnStringJoin.java:31) > at org.basex.query.func.fn.FnStringJoin.item(FnStringJoin.java:19) > at org.basex.query.expr.ParseExpr.value(ParseExpr.java:71) > at org.basex.query.expr.Pipeline.eval(Pipeline.java:96) > at org.basex.query.expr.Pipeline$1.next(Pipeline.java:65) > at org.basex.query.scope.MainModule$1.next(MainModule.java:80) > at org.basex.http.restxq.RestXqResponse.serialize(RestXqResponse.java:81) > at org.basex.http.web.WebResponse.create(WebResponse.java:58) > at org.basex.http.restxq.RestXqServlet.run(RestXqServlet.java:70) > at org.basex.http.BaseXServlet.service(BaseXServlet.java:60) > at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614) > at org.eclipse.jetty.ee10.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1388) > at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:754) > at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1642) > at org.eclipse.jetty.ee10.websocket.servlet.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:199) > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601) > at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1556) > at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:871) > at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:449) > at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:469) > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:546) > at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:719) > at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1253) > at org.eclipse.jetty.compression.server.CompressionHandler.handle(CompressionHandler.java:343) > at org.eclipse.jetty.server.Server.handle(Server.java:197) > at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:804) > at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:420) > at org.eclipse.jetty.server.internal.HttpConnection$FillableCallback.succeeded(HttpConnection.java:1790) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) > at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:54) > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492) > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428) > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401) > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255) > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204) > at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:317) > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:1009) > at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1240) > at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1194) > at java.base/java.lang.Thread.run(Thread.java:1583) > > On 7/16/26 11:54, Christian Grün wrote: > >> Hi Marco, >> >> Sorry for the unexpected changes that will surface with BaseX 13, which include removal of server-side web forwarding (web:forward) and, as you noticed, the mixture of updates and results via MIXUPDATES. The option was not used in any client projects that we are, or have been, involved in in recent years. Its semantics needed to be thought through for every extension of XQuery 4.0, and it was all proprietary work, as there will be no version 4 of W3 XQuery Update Facility. >> >> Due to our limited Open-Source resources, we need to focus on the development our latest releases. However, we do produce backports for older versions of BaseX for contracted clients. We could think about doing this for specific bug of version 12 as well. >> >> The bug you have encountered is certainly something we should understand. Can you reproduce it with the current 13 branch? If yes, could you possibly provide us with a self-contained example? >> >> All the best, >> Christian >> ________________________________________ >> >> Von: Marco Lettere via BaseX-Talk >> [<basex-talk at mailman.uni-konstanz.de>](mailto:basex-talk at mailman.uni-konstanz.de) >> Gesendet: Donnerstag, 16. Juli 2026 11:05 >> An: Gunther Rademacher; >> basex-talk at mailman.uni-konstanz.de >> Betreff: [basex-talk] Incompatibility between 12.4 and 11.7 >> >> Dear all, >> >> I've left the mail related the import issue we had few days ago as reference because the new issue relates somehow. >> >> We have two basex instances one that acts as a repository and one that acts as orchestrator publishing REST services and connecting to the repository through the client:connect, client:query, client:close APIs. >> >> We had to leave the repository on 11.7 because in 12.4 we have the problem with importing modules with semver and dots. We cannot move it to the patched version because that one is already on the 13 route which removes MIXUPDATES causing the de facto invalidation of our ten years old codebase which heavily relies on this option and it will just cost too much effort for us to refactor everything. >> >> So we moved only the orchestrator to 12.4 but now we have an issue because we cannot access resources that are stored in databases as documents. >> >> We enter the container that runs repository and do (suppose testdb already exists): >> >> BaseX 11.7 [Standalone] >> >>> XQUERY client:query(client:connect("localhost", 1984, "admin", "..."), "db:put-value('testdb', document{<doc/>}, 'test')") >> >> Query "basex" executed in 7.0 ms. >> >>> XQUERY client:query(client:connect("localhost", 1984, "admin", "..."), "db:get-value('testdb', 'test')") >> >> <doc/> >> Query "basex" executed in 14.5 ms. >> >> Fine. I can access the document also from dba. Then I enter the container that runs orchestrator with 12.4 and do: >> >> BaseX 12.4 [Standalone] >> >>> XQUERY client:query(client:connect("repository", 1984, "admin", "..."), "db:get-value('testdb', 'test')") >> >> Improper use? Potential bug? Your feedback is welcome: >> Contact: >> basex-talk at mailman.uni-konstanz.de[<mailto:basex-talk at mailman.uni-konstanz.de>](mailto:basex-talk at mailman.uni-konstanz.de) >> Version: BaseX 12.4 >> Java: Alpine, 17.0.12 >> OS: Linux, amd64 >> Stack Trace: >> java.lang.NullPointerException: Cannot invoke "org.basex.query.value.type.Type.id()" because the return value of "org.basex.query.value.type.Types.type(int)" is null >> at org.basex.api.client.Query.cache(Query.java:125) >> at org.basex.api.client.ClientQuery.cache(ClientQuery.java:117) >> at org.basex.query.func.client.ClientQuery.value(ClientQuery.java:40) >> at org.basex.query.expr.ParseExpr.iter(ParseExpr.java:66) >> at org.basex.query.scope.MainModule.iter(MainModule.java:53) >> at org.basex.query.QueryContext.lambda$iter$4(QueryContext.java:392) >> at org.basex.query.QueryContext.run(QueryContext.java:792) >> at org.basex.query.QueryContext.iter(QueryContext.java:392) >> at org.basex.query.QueryProcessor.iter(QueryProcessor.java:98) >> at org.basex.core.cmd.AQuery.run(AQuery.java:89) >> at org.basex.core.Command.run(Command.java:233) >> at org.basex.core.Command.execute(Command.java:93) >> at org.basex.api.client.LocalSession.execute(LocalSession.java:131) >> at org.basex.api.client.Session.execute(Session.java:36) >> at org.basex.core.CLI.execute(CLI.java:98) >> at org.basex.core.CLI.execute(CLI.java:81) >> at org.basex.BaseX.console(BaseX.java:188) >> at org.basex.BaseX.<init>(BaseX.java:163) >> at org.basex.BaseX.main(BaseX.java:44) >> >> Query "basex" executed in 26.07 ms. >> >> This happens only when data is stored as document. If I store the xml without document wrapper it works as expected. >> >> Is there an actual incompatibility between the two versions or is this a bug? >> >> Thanks and sorry for being verbose but I feel like it's important to document that removal of something like MIXUPDATES can cause a notable butterfly effect and it should probably be balloted or somehow anticipated. >> >> Marco. >> >> On 7/15/26 09:29, Gunther Rademacher wrote: >> Hello Marco, >> >> thank you for reporting this. It is an unwanted side effect of the changes that were made for PR 2566 [1], which went into BaseX 12.1. >> >> It has been handled by PR 2720 [2], and the fix is now available in the latest snapshot [3]. >> >> Note that a module already installed under the old incorrect path should be reinstalled to pick up the corrected location. The reinstall restores resolution, but the previously misplaced file (e.g. test/v1/0/0.xqm) is left behind. It can be left there with no harm, but it can also be removed manually if you want a clean repository. >> >> Best regards, >> Gunther >> >> [1] >> https://github.com/BaseXdb/basex/pull/2566 >> [2] >> https://github.com/BaseXdb/basex/pull/2720 >> [3] >> https://files.basex.org/releases/latest/ >> On 7/13/2026 1:35 PM, Marco Lettere via BaseX-Talk wrote: >> Dear all, >> >> I've noticed moving from 11.9 to 12.3 that one import statement got lost and was no longer able to find corresponding module. >> >> I noticed that the way the file is placed in the repo has changed and it seems as if dots now separate content into subfolders. Thus test:v1.0.0 becomes test/v1/0/0/0.xqm. >> >> The problem is that it somehow fails to resolve. >> >> I could reproduce by having this module /repo install/(ed): >> >> module namespace _ = "test:v1.0.0"; >> declare variable $_:A := 1; >> >> it is now placed into *repo/test/v1/0/0.xqm* whereas I'm pretty sure it was placed in* repo/test/v1.0.0.xqm* before. >> >> And then refer to it with: >> >> import module namespace _ = "test:v1.0.0"; >> >> It statically fails with: "Module not found test:v1.0.0". >> >> I can try to rename but using semver tags is something rather frequent so I'd like to know what underlies the issue. >> >> Thank you. >> >> Marco.