exist-open — Open discussion

Re: [Exist-open] Query broken since trying to upgrade from ExistDB 2.2 to 6.0.1

[Mansell, G. <Gar...@ri...>]

Hi Pieter, many thanks for your confirmation.

I have heard back from an ExistDB Dev that thinks I have stumbled across a bug/regression in the 5.4.1, 6.0 and 6.0.1 releases (4.10 seems to be OK).

Issue is tracked here now: https://github.com/eXist-db/exist/issues/4262

Hopefully there will be a new release soon to fix the issue.

Best Regards

Gary

--------------------------------------------------------------------------------------------------------------------------------------------------------------
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those
of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Directors
are authorised to enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and
other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and
any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail.
"Ricardo" means Ricardo plc and its subsidiary companies.
Ricardo plc is a public limited company registered in England with registered number 00222915.
The registered office of Ricardo plc is Shoreham Technical Centre, Shoreham-by Sea, West Sussex, BN43 5FG.
--------------------------------------------------------------------------------------------------------------------------------------------------------------

Re: [Exist-open] Query broken since trying to upgrade from ExistDB 2.2 to 6.0.1

[Pieter L. <pie...@be...>]

Hi Mansell,

I am not an expert of the matter, but I can confirm 
that*util:document-id#1* returns an error, also when I run your XQuery 
on a collection of my own. I suspect that the internal document ID is 
not longer an int, and that the function *util:document-id#1* may no 
longer be functional.

You could try removing line 21 entirely; if no code is dependent on 
*<id>* then you may be fine. I would expect more things to break in 
other parts of the code though, as there have been quite a few changes 
between 2.2 and 4/5/6.

Best
Pieter

On 01/03/2022 12:48, Mansell, Gary wrote:
> Hi, firstly, apologies - I am a system admin not a developer, so I don't know much about ExistDB and XQuery. I have a System that I need to ugprade to the latest version of ExistDB and I have found that it errors when run in the latest 6.0.1 release.
>
> This is the error when I run the query via a browser:
>
> <exception>
> <path>/db/apps/dwhQueries/getFilesToProcessGrouped</path>
> <message>err:FORG0001 can not convert '[I@6161ddcc' to xs:int [at line 21, column 7, source: /db/apps/dwhQueries/getFilesToProcessGrouped]</message>
> </exception>
>
>
>
> This is the code of the query referenced above (line 21, column 7 is the line with this in it: "util:document-id($x)":
>
> xquery version "3.0";
>
>
> let $allItems := (for $x in collection('/db/apps/dwh1') order by util:document-name($x) ascending return $x)
> let $totalCnt := count($allItems)
> let $toTake := 100
> return
> <filesToProcess>
> <TotalItemsInQueue>{ $totalCnt }</TotalItemsInQueue>
> {
> let $topN := $allItems[position() le $toTake]
> let $returnedItemsCnt := count($topN)
> return
> (<ItemsReturned>{ $returnedItemsCnt }</ItemsReturned>,
> <Files>{
> for $x in $topN
> return
> <file>
> <name>{ util:document-name($x) }</name>
> <uri>{ document-uri($x) }</uri>
> <id>{ util:document-id($x) }</id>
> <Objs>{
> for $item in $x//Part
> group by $id := $item/ID, $type := $item/Type, $operation := $item/Operation, $branch := $item/Branch, $perColID := $item/PerColID, $pnWfProcessID := $item/ProcessID
> return
> <Obj>
> {$id}
> {$branch}
> {$perColID}
> {$type}
> {$pnWfProcessID}
>
> <Count>{ count($item) }</Count>
> { $operation }
> </Obj>
> }</Objs>
> </file>
> }</Files>)
> }
> </filesToProcess>
>
>
> As far as I can understand there seems to be a problem in the new version of ExistDB casting the Document ID to an Int - why would this be when this worked fine in version 2.2. Have some things changed in this area since 2.2?
>
>
> This is the xml file in dwh1 that it is trying to query:
>
>
> 1646127543559_10488.xml
>
> <Parts>
>      <Part>
>          <ID>1420709307</ID>
>          <Branch>1420709306</Branch>
>          <Type>wt.part.WTPart</Type>
>          <Operation>NEW_VERSION</Operation>
>      </Part>
>      <Part>
>          <ID>1420709308</ID>
>          <Type>wt.folder.IterFolderMemberLink</Type>
>          <Operation>POST_MODIFY</Operation>
>      </Part>
>      <Part>
>          <ID>1420709304</ID>
>          <Type>wt.part.WTPartMaster</Type>
>          <Operation>NEW_VERSION</Operation>
>      </Part>
> </Parts>
>
>
>
> Any advice/help would be appreciated as I must upgrade ExistDB version for security reasons, yet this error is stopping me.
>
> Thanks
>
> Gary
>
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
> This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system.
> Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those
> of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Directors
> are authorised to enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and
> other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and
> any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail.
> "Ricardo" means Ricardo plc and its subsidiary companies.
> Ricardo plc is a public limited company registered in England with registered number 00222915.
> The registered office of Ricardo plc is Shoreham Technical Centre, Shoreham-by Sea, West Sussex, BN43 5FG.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

-- 
Pieter Lamers
John Benjamins Publishing Company
Postal Address: P.O. Box 36224, 1020 ME AMSTERDAM, The Netherlands
Visiting Address: Klaprozenweg 75G, 1033 NN AMSTERDAM, The Netherlands
Warehouse: Kelvinstraat 11-13, 1446 TK PURMEREND, The Netherlands
tel: +31 20 630 4747
web:www.benjamins.com

[Exist-open] Query broken since trying to upgrade from ExistDB 2.2 to 6.0.1

[Mansell, G. <Gar...@ri...>]

Hi, firstly, apologies - I am a system admin not a developer, so I don't know much about ExistDB and XQuery. I have a System that I need to ugprade to the latest version of ExistDB and I have found that it errors when run in the latest 6.0.1 release.

This is the error when I run the query via a browser:

<exception>
<path>/db/apps/dwhQueries/getFilesToProcessGrouped</path>
<message>err:FORG0001 can not convert '[I@6161ddcc' to xs:int [at line 21, column 7, source: /db/apps/dwhQueries/getFilesToProcessGrouped]</message>
</exception>



This is the code of the query referenced above (line 21, column 7 is the line with this in it: "util:document-id($x)":

xquery version "3.0";


let $allItems := (for $x in collection('/db/apps/dwh1') order by util:document-name($x) ascending return $x)
let $totalCnt := count($allItems)
let $toTake := 100
return
<filesToProcess>
<TotalItemsInQueue>{ $totalCnt }</TotalItemsInQueue>
{
let $topN := $allItems[position() le $toTake]
let $returnedItemsCnt := count($topN)
return
(<ItemsReturned>{ $returnedItemsCnt }</ItemsReturned>,
<Files>{
for $x in $topN
return
<file>
<name>{ util:document-name($x) }</name>
<uri>{ document-uri($x) }</uri>
<id>{ util:document-id($x) }</id>
<Objs>{
for $item in $x//Part
group by $id := $item/ID, $type := $item/Type, $operation := $item/Operation, $branch := $item/Branch, $perColID := $item/PerColID, $pnWfProcessID := $item/ProcessID
return
<Obj>
{$id}
{$branch}
{$perColID}
{$type}
{$pnWfProcessID}

<Count>{ count($item) }</Count>
{ $operation }
</Obj>
}</Objs>
</file>
}</Files>)
}
</filesToProcess>


As far as I can understand there seems to be a problem in the new version of ExistDB casting the Document ID to an Int - why would this be when this worked fine in version 2.2. Have some things changed in this area since 2.2?


This is the xml file in dwh1 that it is trying to query:


1646127543559_10488.xml

<Parts>
    <Part>
        <ID>1420709307</ID>
        <Branch>1420709306</Branch>
        <Type>wt.part.WTPart</Type>
        <Operation>NEW_VERSION</Operation>
    </Part>
    <Part>
        <ID>1420709308</ID>
        <Type>wt.folder.IterFolderMemberLink</Type>
        <Operation>POST_MODIFY</Operation>
    </Part>
    <Part>
        <ID>1420709304</ID>
        <Type>wt.part.WTPartMaster</Type>
        <Operation>NEW_VERSION</Operation>
    </Part>
</Parts>



Any advice/help would be appreciated as I must upgrade ExistDB version for security reasons, yet this error is stopping me.

Thanks

Gary



--------------------------------------------------------------------------------------------------------------------------------------------------------------
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those
of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Directors
are authorised to enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and
other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and
any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail.
"Ricardo" means Ricardo plc and its subsidiary companies.
Ricardo plc is a public limited company registered in England with registered number 00222915.
The registered office of Ricardo plc is Shoreham Technical Centre, Shoreham-by Sea, West Sussex, BN43 5FG.
--------------------------------------------------------------------------------------------------------------------------------------------------------------

Re: [Exist-open] import xquery modules different between 5.4.1 and 5.1.1

[Pieter L. <pie...@be...>]

Hi Jens,

According to my understanding of how things work, there is no need to 
import the same module with a different namespace prefix within the same 
main module. If you are using a different namespace prefix in a 
different module that is fine, as long as it is defined there with that 
namespace. Within the module for which you are showing the Prolog you 
don't call the same function using different prefixes, are you? I cannot 
think of any good reason why that might be.

Best
Pieter

On 21/02/2022 18:45, Jens Tischler via Exist-open wrote:
>
> Hi, all,
>
> at a customer of mine we have an exist 5.1.1 (as well 5.3.1) which 
> works fine. Now I wanted to have a test with a higher version of exist 
> and I took 6.0.1.
>
> With the same set of xquery I ran into trouble with the validation of 
> imported xquery modules. I always get messages like
>
> ... Prolog has more than one imported module that defines the 
> function: {http://www.dosco.de/xquery/ref/cmn}getNamebyNode#3
>
> The same problem occurs using 5.4.1.
>
> Of course I needed to import the same submodule in several modules.
>
> For example: ../ref.xqm (line 14) and some other xqm more import 
> ./cmn.xqm (line 27) as well.
>
> But this seemed not to be a problem using 5.3.1. But with 5.4.1 it does!
>
> In some cases I even got different results changing the order of the 
> imports. But I can't rework the whole import architecture. Or need I?
>
> Has anybody an idea which has changed in this case between 5.3.1 and 
> 5.4.1?
>
> Thanks and regards
> Jens
>
> -- 
> __________________________________________________________________________
> Jens Tischler, DOSCO
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

-- 
Pieter Lamers
John Benjamins Publishing Company
Postal Address: P.O. Box 36224, 1020 ME AMSTERDAM, The Netherlands
Visiting Address: Klaprozenweg 75G, 1033 NN AMSTERDAM, The Netherlands
Warehouse: Kelvinstraat 11-13, 1446 TK PURMEREND, The Netherlands
tel: +31 20 630 4747
web:www.benjamins.com

[Exist-open] import xquery modules different between 5.4.1 and 5.1.1

[Jens T. <tis...@do...>]

Hi, all,

at a customer of mine we have an exist 5.1.1 (as well 5.3.1) which works 
fine. Now I wanted to have a test with a higher version of exist and I 
took 6.0.1.

With the same set of xquery I ran into trouble with the validation of 
imported xquery modules. I always get messages like

... Prolog has more than one imported module that defines the function: 
{http://www.dosco.de/xquery/ref/cmn}getNamebyNode#3

The same problem occurs using 5.4.1.

Of course I needed to import the same submodule in several modules.

For example: ../ref.xqm (line 14) and some other xqm more import 
./cmn.xqm (line 27) as well.

But this seemed not to be a problem using 5.3.1. But with 5.4.1 it does!

In some cases I even got different results changing the order of the 
imports. But I can't rework the whole import architecture. Or need I?

Has anybody an idea which has changed in this case between 5.3.1 and 5.4.1?

Thanks and regards
Jens

-- 
__________________________________________________________________________
Jens Tischler, DOSCO

[Exist-open] [ANN] eXist-db 4.10.0, 5.4.1, and 6.0.1 released

[Adam R. <ad...@ex...>]

Dear eXist-db users,

Happy Valentines Day!

We have recently published new eXist-db releases for you. The versions include:

* 6.0.1 which is much the same as 5.4.1 but with two small API breaking changes.

* 5.4.1 which is a small bug fixed version of the recent 5.4.0 release.

* 4.9.0 and 4.10.0 as updates for those still using the legacy 4.x.x line.

You can find all the versions, associated release notes and downloads
here: https://github.com/exist-db/exist/releases

Kind regards. Adam.

-- 
Adam Retter

eXist Core Developer
{ United Kingdom }
ad...@ex...

Re: [Exist-open] eXist 6.0.0 with OxygenXML

[Josef W. UL <jwe...@hi...>]

Hi Marc

This is what I did, I didn't notice my mail client didn't add the 
mailing list (I think I clicked on "reply all"). This time it should be 
there.

Thank you for your reply! I did indeed use my old connection from 
eXist-db 5.3.x. I will correct that and see what's happening.

Josef

On 09.02.22 14:02, Marc de Graauw wrote:
> Hi Josef,
>
> I don't see your message appearing on the mailing list, maybe you sent 
> it to just me.
>
> Anyway, I did have some Ace* errors with eXist 6 too, but in my case 
> those were caused by me not having made a new eXist-db connection in 
> the Oxygen data sources with the eXist 6 libraries - I still had an 
> older eXist 5 connection which I used. Hope this is not what's 
> happening in your case too.
>
> Marc
>
> On Wed, 9 Feb 2022 at 08:58, Josef Wetzel UL 
> <jwe...@hi...> wrote:
>
>     Hi Marc, Hi everybody
>
>     On eXist-db 6.0.0 and Oxygen:
>     I work with Oxygen Editor 23.1 and connect it to eXist-db-6.0.0 via
>     Database Soruce -> eXist-db as described in Oxygen help.
>
>     In the beginning everything worked as expected. But then I came
>     across a
>     problem:
>
>     When I wanted to browse a certain collection in my eXist-db in
>     Oxygen, I
>     received an error message saying something like "aceAccess ...".
>     Oxygen
>     refused to show the contents of this collection.
>     I then realised, that I had some documents in this collection, which
>     where protected not only by the common flags rwx for owner, group and
>     others but also by an ACL. This ACL triggered the error. I removed
>     the
>     ACL and everything worked fine. In this case I can rethink the
>     document
>     protection to work without ACL, but this might be a problem when
>     using
>     Oxygen with eXist-db-6.0.0.
>
>     Josef
>
>     On 01.02.22 17:05, Marc de Graauw wrote:
>     > I've been trying eXist 6.0.0 on my local machine, OxygenXML
>     seems to
>     > work fine - I can create, delete, execute. The blog mentions
>     > incompatibilities - any hints as to what kind of trouble I
>     should be
>     > looking for?
>     >
>     > Marc
>     >
>     >
>     > _______________________________________________
>     > Exist-open mailing list
>     > Exi...@li...
>     > https://lists.sourceforge.net/lists/listinfo/exist-open
>
>
>
>
> -- 
>
> Groeten,
>
> Marc

[Exist-open] [exist-open] off-topic announcement: Fore replaces betterFORM

[Joern T. <joe...@gm...>]

Sorry for this slightly off-topic posting:

For those who have used betterFORM in eXist-db and those who have to edit
some structured XML please read on.

There's a new pre-release of Fore (1.0.0-2) available at
https://github.com/Jinntec/Fore/releases/tag/v1.0.0-2

We have successfully ported a complex betterFORM XForms page with about
1.500 lines of code (reduced to about 900 lines afterwards), using about 20
data instances and deeply nested repeats to Fore. Unfortunately betterFORM
is not compatible with latest eXist-db releases any more but Fore is here
as a replacement. It's now pure client-side and requires no  setup.

However we plan a fore-exist module to make it even easier to use it within
your eXist-db apps and and provide a generic server-side validation
facility.

If you like it, I would appreciate a github star.

If you find things not being covered I'm open for feature requests and
discussions.

Thanks for listening,

Joern

Re: [Exist-open] Status of eXist-db 5.3.1, 5.4, 6.0?

[Craig A. B. <cra...@ma...>]

> On Jan 28, 2022, at 4:12 AM, Jo Calder <Jo....@ha...> wrote:
> 
> Hi all,
> 
> I see that there's new eXist-db (6.0 reached via http://exist-db.org/exist/apps/homepage/index.html#downloads, and clicking on the 5.3.1 link).   Did I miss the announcement for 6.0?  
> 
> The new drop happened just as I was preparing a release.  It would be really useful to know whether any regressions were detected in 5.3.1 (relative to 5.2) which are corrected in 5.4/6.0.  Can anyone supply that info?  

According to the publicly-available community call meeting minutes from Monday:

<https://docs.google.com/document/d/1eycQBp0CR9_B4fcGPt-1et4Ymgt4Fpzj5YcKhZp3Ln4/edit#heading=h.ei4sqy3ojpkl>

The announcements for 5.4.0 and 6.0.0 were held back because of a problem discovered with Monex in those releases.  That problem seems to have been addressed:

<https://github.com/eXist-db/exist/pull/4215>

and releases of 5.4.1 and 6.0.1 that include it should be out soon.  The fix is in eXist itself and can't be fixed by upgrading Monex.

The small team of volunteers that produces these releases is understandably a bit behind on their paperwork and has some work to get the issue tracker caught up with reality, but I would expect master tickets for the upcoming releases to appear soon on the milestones page:

<https://github.com/eXist-db/exist/milestones>


________________________________________
Craig A. Berry

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

[Exist-open] eXist 6.0.0 with OxygenXML

[Marc de G. <mar...@gm...>]

I've been trying eXist 6.0.0 on my local machine, OxygenXML seems to work
fine - I can create, delete, execute. The blog mentions incompatibilities -
any hints as to what kind of trouble I should be looking for?

Marc

Re: [Exist-open] Status of eXist-db 5.3.1, 5.4, 6.0?

[Martin M. <mar...@no...>]

I’m not quite sure how to read the caveats about eXist 6.0.  I think they mean that if you are using oXygen with eXist you’re better off sticking with 5.4. Is that correct?  Or are the security concerns of such rarefied quality that it doesn’t matter a whole lot.

Re: [Exist-open] Status of eXist-db 5.3.1, 5.4, 6.0?

[Eduard D. <ed...@fr...>]

https://exist-db.org/exist/apps/wiki/blogs/eXist//eXistdb540
https://exist-db.org/exist/apps/wiki/blogs/eXist//eXistdb600 id="-x-evo-selection-start-marker">

-----Original Message-----
From: Jo Calder <Jo....@ha...>
To: exi...@li...
Subject: [Exist-open] Status of eXist-db 5.3.1, 5.4, 6.0?
Date: Fri, 28 Jan 2022 10:12:16 +0000

Hi all,
I see that there's new eXist-db (6.0 reached via 
http://exist-db.org/exist/apps/homepage/index.html#downloads, and
clicking on the 5.3.1 link).   Did I miss the announcement for 6.0?  

The new drop happened just as I was preparing a release.  It would be
really useful to know whether any regressions were detected in 5.3.1
(relative to 5.2) which are corrected in 5.4/6.0.  Can anyone supply
that info?  

With thanks, -- Jo

_______________________________________________Exist-open mailing 
lis...@li...
https://lists.sourceforge.net/lists/listinfo/exist-open

-- 
Eduard Drenth, Software Architekt

ed...@fr...

Doelestrjitte 8
8911 DX  Ljouwert
+31 58 234 30 47
+31 62 094 34 28 (privé)

skype: eduarddrenth
https://github.com/eduarddrenth
frisian.eu
gpg: https://pgp.surfnet.nl/pks/lookup?search=eduarddrenth


Op freed bin ik thús/wurkje ik minder

[Exist-open] Status of eXist-db 5.3.1, 5.4, 6.0?

[Jo C. <Jo....@ha...>]

Hi all,

I see that there's new eXist-db (6.0 reached via
http://exist-db.org/exist/apps/homepage/index.html#downloads, and clicking
on the 5.3.1 link).   Did I miss the announcement for 6.0?

The new drop happened just as I was preparing a release.  It would be
really useful to know whether any regressions were detected in 5.3.1
(relative to 5.2) which are corrected in 5.4/6.0.  Can anyone supply that
info?

With thanks, -- Jo

[Exist-open] baffled by password problems

[Martin M. <mar...@no...>]

I have run exist 5.3.1 on my Mac mini with Montero. I uninstalled it and also removed the org.exist directory because  some TEI Publisher icons wouldn’t go away even after I delete the apps vi the Java admin client.

Then I reinstalled eXist from scratch.  But the new installation refuses to register passwords. In the documentation there is an icon that suggests that in the first request for setting an admin password there is a screen  that asks you to confirm the password. That screen doesn’t show, but unless my memory tricks me it wasn’t there on the earlier installation, but it accepted the initial admin passs word without confirmation and let me create another user with a password.

I repeated the procedure several times to no avail. So now I’m in a situation where on an otherwise functional Mac I can’t install eXist.

I’ll be grateful for any advice

Re: [Exist-open] Instrumenting XQL for millisecond time

[Len S. <le...@wi...>]

Yes, Monex tracing works great.

--len

On Jan 20, 2022, at 5:57 AM, Dannes Wessels <di...@ex...<mailto:di...@ex...>> wrote:

Hi,

Did you have a look at the tracing function of monex?

The function you mention requires to return the same time, according to the w3c spec.

Regards

Dannes

Sent from my iPhone

On 16 Jan 2022, at 22:34, Len Schultz <le...@wi...<mailto:le...@wi...>> wrote:

 I’m trying to instrument my XQL so I can see how long functions take to execute.

I tried current-dateTime(), but that returns the same millisecond timestamp at all points of the code, apparently being the time the XQL started.  Is there a way to do this?  Marklogic seems to have xdmp:elapsed-time(), but I don’t see something similar in eXist.  But even that may not work for XQL being an OOO functional language.

What’s the best way to profile the latency of functions?

--len

_______________________________________________
Exist-open mailing list
Exi...@li...<mailto:Exi...@li...>
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] Instrumenting XQL for millisecond time

[Dannes W. <di...@ex...>]

Hi,

Did you have a look at the tracing function of monex?

The function you mention requires to return the same time, according to the w3c spec.

Regards

Dannes

Sent from my iPhone

> On 16 Jan 2022, at 22:34, Len Schultz <le...@wi...> wrote:
> 
>  I’m trying to instrument my XQL so I can see how long functions take to execute.
> 
> I tried current-dateTime(), but that returns the same millisecond timestamp at all points of the code, apparently being the time the XQL started.  Is there a way to do this?  Marklogic seems to have xdmp:elapsed-time(), but I don’t see something similar in eXist.  But even that may not work for XQL being an OOO functional language.
> 
> What’s the best way to profile the latency of functions?
> 
> --len
> 
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] Exchange JETTY version in eXist 5

[Omar S. <Oma...@oe...>]

Hello,

Am 17.01.2022 um 09:25 schrieb Jens Tischler via Exist-open:
>
> Does anyone know how to switch JETTY to a higher version in eXist 5 
> (5.1.1)? Exchanging the JARs seems not to be sufficient. d regards
> Jens
>
I have good experience in rebuilding exist-db with just some 
dependencies updated. Especially log4j and jetty works well.

Best regards

-- 
Mag. Ing. Omar Siam
Austrian Center for Digital Humanities and Cultural Heritage
Österreichische Akademie der Wissenschaften | Austrian Academy of Sciences
Stellvertretende Behindertenvertrauensperson | Deputy representative for disabled persons
Wohllebengasse 12-14, 1040 Wien, Österreich | Vienna, Austria
T: +43 1 51581-7295
oma...@oe... | www.oeaw.ac.at/acdh

[Exist-open] Exchange JETTY version in eXist 5

[Jens T. <tis...@do...>]

Hello,

this is Jens from DOSCO.

Does anyone know how to switch JETTY to a higher version in eXist 5 
(5.1.1)? Exchanging the JARs seems not to be sufficient.

Background: Our customer recognized some security issues with the 
built-in JETTY 9.4.24.

Thanks and regards
Jens

-- 
__________________________________________________________________________
<> DOSCO Document Systems Consulting GmbH
Jens Tischler

phone +49 162 4664334
      (+49 6221 1486 25)
mail  tis...@do...
web   http://www.dosco.de

       DOSCO Document Systems Consulting GmbH
       Mannheimer Strasse 1
       69115 Heidelberg, GERMANY

       Handelsregister:  Mannheim HRB 335122
       Geschäftsführung: Robert Erfle

Re: [Exist-open] Instrumenting XQL for millisecond time

[Len S. <le...@wi...>]

Sava,

Can you please share link to the eXist profiler?

--len

On Jan 16, 2022, at 1:37 PM, sju...@mr...<mailto:sju...@mr...> wrote:


Hi Len,

we utilize eXist profiler for this purpose.

Cheers,

Sava

On 2022-01-16 12:00, Len Schultz wrote:

I'm trying to instrument my XQL so I can see how long functions take to execute.

I tried current-dateTime(), but that returns the same millisecond timestamp at all points of the code, apparently being the time the XQL started.  Is there a way to do this?  Marklogic seems to have xdmp:elapsed-time(), but I don't see something similar in eXist.  But even that may not work for XQL being an OOO functional language.

What's the best way to profile the latency of functions?

--len

_______________________________________________
Exist-open mailing list
Exi...@li...<mailto:Exi...@li...>
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] Instrumenting XQL for millisecond time

[Len S. <le...@wi...>]

Thanks.  I didn’t know about this.  It helps a lot.

--len

On Jan 16, 2022, at 1:55 PM, sju...@mr...<mailto:sju...@mr...> wrote:


It is part of the eXist install

http://localhost:8080/exist/apps/monex/index.html

Cheers,

Sava



On 2022-01-16 13:47, Len Schultz wrote:

Sava,

Can you please share link to the eXist profiler?

--len

On Jan 16, 2022, at 1:37 PM, sju...@mr...<mailto:sju...@mr...> wrote:

Hi Len,

we utilize eXist profiler for this purpose.

Cheers,

Sava

On 2022-01-16 12:00, Len Schultz wrote:

I'm trying to instrument my XQL so I can see how long functions take to execute.

I tried current-dateTime(), but that returns the same millisecond timestamp at all points of the code, apparently being the time the XQL started.  Is there a way to do this?  Marklogic seems to have xdmp:elapsed-time(), but I don't see something similar in eXist.  But even that may not work for XQL being an OOO functional language.

What's the best way to profile the latency of functions?

--len

_______________________________________________
Exist-open mailing list
Exi...@li...<mailto:Exi...@li...>
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] Instrumenting XQL for millisecond time

[Craig B. <cra...@ma...>]

Profiler certainly works for some use cases.  If there is a particular beast of a function that routinely causes performance problems, I will often do something like this to keep an eye on just how bad it is:

    let $start-time := util:system-time()
. . .
    let $seconds := (util:system-time() - $start-time) div xs:dayTimeDuration("PT1S")
    let $x := console:log("Completed in " || $seconds || "s.")

> On Jan 16, 2022, at 3:37 PM, sju...@mr... wrote:
> 
> Hi Len,
> 
> we utilize eXist profiler for this purpose.
> 
> Cheers,
> 
> Sava
> 
> On 2022-01-16 12:00, Len Schultz wrote:
> 
>> I'm trying to instrument my XQL so I can see how long functions take to execute.
>>  
>> I tried current-dateTime(), but that returns the same millisecond timestamp at all points of the code, apparently being the time the XQL started.  Is there a way to do this?  Marklogic seems to have xdmp:elapsed-time(), but I don't see something similar in eXist.  But even that may not work for XQL being an OOO functional language.
>>  
>> What's the best way to profile the latency of functions?
>> 
>> --len
>> 
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>  
>  
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

________________________________________
Craig A. Berry

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Re: [Exist-open] Instrumenting XQL for millisecond time

[Jean-Paul R. <re...@gm...>]

 util:system-time() does what you need.



On Sun, Jan 16, 2022 at 10:34 PM Len Schultz <le...@wi...> wrote:

> I’m trying to instrument my XQL so I can see how long functions take to
> execute.
>
> I tried current-dateTime(), but that returns the same millisecond
> timestamp at all points of the code, apparently being the time the XQL
> started.  Is there a way to do this?  Marklogic seems to have
> xdmp:elapsed-time(), but I don’t see something similar in eXist.  But even
> that may not work for XQL being an OOO functional language.
>
> What’s the best way to profile the latency of functions?
>
> --len
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] Instrumenting XQL for millisecond time

[<sju...@mr...>]

 

Hi Len, 

we utilize eXist profiler for this purpose. 

Cheers, 

Sava 

On 2022-01-16 12:00, Len Schultz wrote: 

> I'm trying to instrument my XQL so I can see how long functions take to execute. 
> 
> I tried current-dateTime(), but that returns the same millisecond timestamp at all points of the code, apparently being the time the XQL started.  Is there a way to do this?  Marklogic seems to have xdmp:elapsed-time(), but I don't see something similar in eXist.  But even that may not work for XQL being an OOO functional language. 
> 
> What's the best way to profile the latency of functions? 
> 
> --len 
> 
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

  

Re: [Exist-open] Instrumenting XQL for millisecond time

[<sju...@mr...>]

 

It is part of the eXist install 

http://localhost:8080/exist/apps/monex/index.html 

Cheers, 

Sava 

On 2022-01-16 13:47, Len Schultz wrote: 

> Sava, 
> 
> Can you please share link to the eXist profiler?  
> 
> --len 
> 
> On Jan 16, 2022, at 1:37 PM, sju...@mr... wrote: 
> 
> Hi Len, 
> 
> we utilize eXist profiler for this purpose. 
> 
> Cheers, 
> 
> Sava 
> 
> On 2022-01-16 12:00, Len Schultz wrote: I'm trying to instrument my XQL so I can see how long functions take to execute. 
> 
> I tried current-dateTime(), but that returns the same millisecond timestamp at all points of the code, apparently being the time the XQL started.  Is there a way to do this?  Marklogic seems to have xdmp:elapsed-time(), but I don't see something similar in eXist.  But even that may not work for XQL being an OOO functional language. 
> 
> What's the best way to profile the latency of functions? 
> 
> --len 
> 
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

  

[Exist-open] Instrumenting XQL for millisecond time

[Len S. <le...@wi...>]

I’m trying to instrument my XQL so I can see how long functions take to execute.

I tried current-dateTime(), but that returns the same millisecond timestamp at all points of the code, apparently being the time the XQL started.  Is there a way to do this?  Marklogic seems to have xdmp:elapsed-time(), but I don’t see something similar in eXist.  But even that may not work for XQL being an OOO functional language.

What’s the best way to profile the latency of functions?

--len