exist-open — Open discussion

[Exist-open] http request read environment variable

[Roy W. <gar...@ya...>]

I had a working SendGrid implementation using httpclient:post where  an API key was sent as header.
Having upgraded to 5.x, httpclient is no longer available so I am using http:send-request. My SendGrid implementation no longer works because the API key is sent as if from a browser, which is perceived at SendGrid's end as a security risk.
The recommendation is to store the API key in an environment variable. I have no idea how or whether this can be achieved in eXist.
Does anyone have any insight on this?
Thanks as ever,Roy

Re: [Exist-open] Fwd: Problem files after a crash

[Joe W. <jo...@gm...>]

Hi Nick,

Great, now that you have a backup, could you please open an issue and, if
possible, attach the backup there? We would also benefit from knowing what
query fails.

Joe

On Tue, Sep 28, 2021 at 10:36 PM Nick Sincaglia <nsi...@nu...>
wrote:

> I found another example of this issue today. I had a file which was
> located here:
>
> /db/apps/core/message-store/data/DEP-42/20210912/193872978031-20210912232055722.xml
>
> My scripts would fail when they tried to process it. I took a backup of
> the database. Then I opened the file in Oxygen, clicked the Format and
> Index icon and then saved it. My scripts processed this file without any
> problem.
>
> I have the database backup and would love to get some help in trying to
> explain what is wrong with this file or the indexes that is causing this
> problem.
>
> Nick
>
> On 9/27/21 9:07 AM, Nick Sincaglia wrote:
>
> Joe,
> I have experienced this issue on various different versions of eXist-db. I
> don't think it is specific to the version I am using.
>
> I have a variety of different eXist-db versions running for different
> clients. I usually try to get a new client using the latest version of
> eXist-db when I first start working with them and unless there is a good
> reason to upgrade, I usually keep them on that version for a while. Every
> new version of eXist-db comes with the potential risk that something that
> was working might break in the new version. So, I am reluctant to upgrade
> unless it there is a clear benefit.
>
> The issue I described is caused by the initial crash. It is just not clear
> to me why the re-index does not address the issue. It is hard to find these
> files as well. Usually I find them because the system is throwing an
> unexplained error. It would be helpful to be able to detect these files
> after a crash to proactively identify them before they cause the system to
> error in unexplained ways.
>
> Nick
>
> On 9/26/21 8:13 PM, Joe Wicentowski wrote:
>
> Hi Nick,
>
> I don't have any suggestions, except perhaps one: Have you considered
> upgrading to eXist 5? It's got a lot of fixes to locking and has been very
> stable for us in production.
>
> Joe
>
> On Sun, Sep 26, 2021 at 5:57 PM Nick Sincaglia <nsi...@nu...>
> wrote:
>
>> I brought this up on the last community call but I wanted to send the
>> e-mail to see if the wider community audience might have some suggestions.
>>
>> I had my eXist-db v4.5 crash a number of weeks ago. I restarted the
>> system, it ran through the data integrity check and everything seemed to be
>> OK. However, later, I noticed one of the files in my system that was not
>> indexed correctly. I could tell this because my file processing script
>> could find the file in the system but I was getting an error that did not
>> make any sense.
>>
>> So, what I decided to do next was to reindex the entire database
>> (xmldb:reindex('/db')). I tried running my script again and I still got the
>> same error. So, next I located the file in the system, opened up the file
>> and made a minor change to the XML file (The small change I made was I
>> added a white space to the end of the file, but I could have made any
>> change.) Then I saved the file. After that, I ran my script and everything
>> worked as expected.
>>
>> What I believe I understand about this issue is that there is something
>> that happens when you save a file, which forces a re-index of a file, which
>> is different then if you run xmldb:reindex(). Also, I have experimented
>> with downloading a collection of documents, then deleting the collection in
>> the database and then uploading the collection to the database using
>> WebDAV. This technique also does not solve the issue. There is something
>> about opening the file, changing it and then saving it that resolves this
>> issue. I was posting this because I see this issue every 6 months or so.
>> Whenever, I am completely stumped by a script not running properly, I have
>> learned to locate the file, modify it in a minor way and resave it and very
>> frequently it resolves my issue.
>>
>> When I brought this up on the community call, I was given 2 suggestions.
>> First, they thought maybe the XML files had a BOM character in them. This
>> is not the case for me because we are not working with any Windows servers.
>> I have seen this BOM character issue before and so I can confidently say,
>> this is not related to a BOM character.
>>
>> The second suggestion was that maybe our index was indexing an attribute
>> instead of a tag. I checked my index and I don't think this is the case. My
>> index file is below.
>> <collection xmlns="http://exist-db.org/collection-config/1.0"
>> <http://exist-db.org/collection-config/1.0>>
>>     <index>
>>         <!-- Disable the old full text index -->
>>         <fulltext default="none" attributes="false"/>
>>         <!-- New full text index based on Lucene indexes for full names
>> and song titles -->
>>         <lucene>
>>             <analyzer
>> class="org.apache.lucene.analysis.standard.StandardAnalyzer"/>
>>             <analyzer id="ws"
>> class="org.apache.lucene.analysis.WhitespaceAnalyzer"/>
>>         </lucene>
>>         <!-- Range indexes for fast ID lookups -->
>>         <range>
>>             <create qname="next-activity" type="xs:string"/>
>>             <create qname="data-exchange-id" type="xs:string"/>
>>             <create qname="data-origin-party-id" type="xs:string"/>
>>             <create qname="data-destination-party-id" type="xs:string"/>
>>             <create qname="release-id" type="xs:string"/>
>>             <create qname="search" type="xs:string"/>
>>             <create qname="delivery-type" type="xs:string"/>
>>             <create qname="queue-date-time" type="xs:string"/>
>>             <create qname="delivery-date-time" type="xs:string"/>
>>             <create qname="workflow-status" type="xs:string"/>
>>             <create qname="event-timestamp" type="xs:dateTime"/>
>>         </range>
>>     </index>
>> </collection>
>>
>> Any thoughts or suggestions are welcome!
>>
>> Nick
>>
>> --
>> Nick Sincaglia
>> President/Founder
>> NueMeta, LLC
>> Digital Media & Technology
>> Phone: +1-...@nu... http://www.nuemeta.com
>> Skype: nsincaglia
>>
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>>
> --
> Sent from my iPhone
>
>
> --
> Nick Sincaglia
> President/Founder
> NueMeta, LLC
> Digital Media & Technology
> Phone: +1-...@nu... http://www.nuemeta.com
> Skype: nsincaglia
>
>
> --
> Nick Sincaglia
> President/Founder
> NueMeta, LLC
> Digital Media & Technology
> Phone: +1-...@nu... http://www.nuemeta.com
> Skype: nsincaglia
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

[Exist-open] Declarative Amsterdam

[Erik S. <er...@xa...>]

The Program for Declarative Amsterdam 2021 (http://declarative.amsterdam/program) has been announced, featuring tutorials and presentations on topics such as Saxon-JS, ixml, XProc, DITA, declarative databases, and the social issues of declarative processes, featuring names such as Betsy Haibel, Debbie Lockett, Steven Pemberton, Erik Siegel, Michael Sperberg-McQueen, and Norm Tovey-Walsh.

 

The conference will be hybrid: you can attend in person or remotely, and is on November 4th and 5th. Registration is open at: https://declarative.amsterdam/submit?model=da-registration.

 

We hope to be see you there, either in person or virtually!

 

Best wishes,

The Declarative Amsterdam Conference Committee.

Re: [Exist-open] Can't list collections

[Roy W. <gar...@ya...>]

 Resolved by reinstalling and db restore.

R.

    On Sunday, 3 October 2021, 12:46:14 BST, Roy Walter via Exist-open <exi...@li...> wrote:  
 
 When trying to list collections in the Java admin client, Oxygen and the Collection Browser I am seeing this error:
org.xmldb.api.base.XMLDBException: Failed to invoke method describeResource in class org.exist.xmlrpc.RpcConnection: Unknown ACE Access TypeFailed to invoke method describeResource in class org.exist.xmlrpc.RpcConnection: Unknown ACE Access Type

I can list collections in eXide and over webdav.
Any ideas?
Thanks,Roy

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

[Exist-open] Can't list collections

[Roy W. <gar...@ya...>]

When trying to list collections in the Java admin client, Oxygen and the Collection Browser I am seeing this error:
org.xmldb.api.base.XMLDBException: Failed to invoke method describeResource in class org.exist.xmlrpc.RpcConnection: Unknown ACE Access TypeFailed to invoke method describeResource in class org.exist.xmlrpc.RpcConnection: Unknown ACE Access Type

I can list collections in eXide and over webdav.
Any ideas?
Thanks,Roy

Re: [Exist-open] Fwd: Problem files after a crash

[<ai...@un...>]

I can support Nick's findings.

One of our resources shows the same or similar behaviour.
Occasionally, a resource cannot be displayed (browser loads the page  
(betterform) without error but 'shows' unbound fields).
The file can be loaded in eXide and looks perfectly normal.
After staring at it und saving the file loads and displays as expected.
Editing is not needed,
Simple Re-indexing, however, does not help.
I didn't try to access the file via scripting.
As an amateur I imagined that the 'memory representation' of the  
resource in eXistDB is altered in some way??

I didn't report an issue because I could not isolate a test case and  
we are using an 'ancient' eXistDb v4.5 with betterform.

reagrds
Peter

Ubuntu 18, eXistDb 4.5, java8_181


Zitat von Nick Sincaglia <nsi...@nu...>:

> I found another example of this issue today. I had a file which was  
> located here:
> /db/apps/core/message-store/data/DEP-42/20210912/193872978031-20210912232055722.xml
>
> My scripts would fail when they tried to process it. I took a backup  
> of the database. Then I opened the file in Oxygen, clicked the  
> Format and Index icon and then saved it. My scripts processed this  
> file without any problem.
>
> I have the database backup and would love to get some help in trying  
> to explain what is wrong with this file or the indexes that is  
> causing this problem.
>
> Nick
>
> On 9/27/21 9:07 AM, Nick Sincaglia wrote:
>> Joe,
>> I have experienced this issue on various different versions of  
>> eXist-db. I don't think it is specific to the version I am using.
>>
>> I have a variety of different eXist-db versions running for  
>> different clients. I usually try to get a new client using the  
>> latest version of eXist-db when I first start working with them and  
>> unless there is a good reason to upgrade, I usually keep them on  
>> that version for a while. Every new version of eXist-db comes with  
>> the potential risk that something that was working might break in  
>> the new version. So, I am reluctant to upgrade unless it there is a  
>> clear benefit.
>>
>> The issue I described is caused by the initial crash. It is just  
>> not clear to me why the re-index does not address the issue. It is  
>> hard to find these files as well. Usually I find them because the  
>> system is throwing an unexplained error. It would be helpful to be  
>> able to detect these files after a crash to proactively identify  
>> them before they cause the system to error in unexplained ways.
>>
>> Nick
>>
>> On 9/26/21 8:13 PM, Joe Wicentowski wrote:
>>> Hi Nick,
>>>
>>> I don't have any suggestions, except perhaps one: Have you  
>>> considered upgrading to eXist 5? It's got a lot of fixes to  
>>> locking and has been very stable for us in production.
>>>
>>> Joe
>>>
>>> On Sun, Sep 26, 2021 at 5:57 PM Nick Sincaglia  
>>> <nsi...@nu... <mailto:nsi...@nu...>> wrote:
>>>
>>>    I brought this up on the last community call but I wanted to send
>>>    the e-mail to see if the wider community audience might have some
>>>    suggestions.
>>>
>>>    I had my eXist-db v4.5 crash a number of weeks ago. I restarted
>>>    the system, it ran through the data integrity check and
>>>    everything seemed to be OK. However, later, I noticed one of the
>>>    files in my system that was not indexed correctly. I could tell
>>>    this because my file processing script could find the file in the
>>>    system but I was getting an error that did not make any sense.
>>>
>>>    So, what I decided to do next was to reindex the entire database
>>>    (xmldb:reindex('/db')). I tried running my script again and I
>>>    still got the same error. So, next I located the file in the
>>>    system, opened up the file and made a minor change to the XML
>>>    file (The small change I made was I added a white space to the
>>>    end of the file, but I could have made any change.) Then I saved
>>>    the file. After that, I ran my script and everything worked as
>>>    expected.
>>>
>>>    What I believe I understand about this issue is that there is
>>>    something that happens when you save a file, which forces a
>>>    re-index of a file, which is different then if you run
>>>    xmldb:reindex(). Also, I have experimented with downloading a
>>>    collection of documents, then deleting the collection in the
>>>    database and then uploading the collection to the database using
>>>    WebDAV. This technique also does not solve the issue. There is
>>>    something about opening the file, changing it and then saving it
>>>    that resolves this issue. I was posting this because I see this
>>>    issue every 6 months or so. Whenever, I am completely stumped by
>>>    a script not running properly, I have learned to locate the file,
>>>    modify it in a minor way and resave it and very frequently it
>>>    resolves my issue.
>>>
>>>    When I brought this up on the community call, I was given 2
>>>    suggestions. First, they thought maybe the XML files had a BOM
>>>    character in them. This is not the case for me because we are not
>>>    working with any Windows servers. I have seen this BOM character
>>>    issue before and so I can confidently say, this is not related to
>>>    a BOM character.
>>>
>>>    The second suggestion was that maybe our index was indexing an
>>>    attribute instead of a tag. I checked my index and I don't think
>>>    this is the case. My index file is below.
>>>    <collection xmlns="http://exist-db.org/collection-config/1.0"
>>>    <http://exist-db.org/collection-config/1.0>>
>>>        <index>
>>>            <!-- Disable the old full text index -->
>>>            <fulltext default="none" attributes="false"/>
>>>            <!-- New full text index based on Lucene indexes for full
>>>    names and song titles -->
>>>            <lucene>
>>>                <analyzer
>>>    class="org.apache.lucene.analysis.standard.StandardAnalyzer"/>
>>>                <analyzer id="ws"
>>>    class="org.apache.lucene.analysis.WhitespaceAnalyzer"/>
>>>            </lucene>
>>>            <!-- Range indexes for fast ID lookups -->
>>>            <range>
>>>                <create qname="next-activity" type="xs:string"/>
>>>                <create qname="data-exchange-id" type="xs:string"/>
>>>                <create qname="data-origin-party-id" type="xs:string"/>
>>>                <create qname="data-destination-party-id"
>>>    type="xs:string"/>
>>>                <create qname="release-id" type="xs:string"/>
>>>                <create qname="search" type="xs:string"/>
>>>                <create qname="delivery-type" type="xs:string"/>
>>>                <create qname="queue-date-time" type="xs:string"/>
>>>                <create qname="delivery-date-time" type="xs:string"/>
>>>                <create qname="workflow-status" type="xs:string"/>
>>>                <create qname="event-timestamp" type="xs:dateTime"/>
>>>            </range>
>>>        </index>
>>>    </collection>
>>>
>>>    Any thoughts or suggestions are welcome!
>>>
>>>    Nick
>>>
>>>    --     Nick Sincaglia
>>>    President/Founder
>>>    NueMeta, LLC
>>>    Digital Media & Technology
>>>    Phone: +1-630-303-7035
>>>    nsi...@nu...  <mailto:nsi...@nu...>       
>>> http://www.nuemeta.com  <http://www.nuemeta.com>
>>>    Skype: nsincaglia
>>>
>>>    _______________________________________________
>>>    Exist-open mailing list
>>>    Exi...@li...
>>>    <mailto:Exi...@li...>
>>>    https://lists.sourceforge.net/lists/listinfo/exist-open
>>>    <https://lists.sourceforge.net/lists/listinfo/exist-open>
>>>
>>> -- 
>>> Sent from my iPhone
>>
>> -- 
>> Nick Sincaglia
>> President/Founder
>> NueMeta, LLC
>> Digital Media & Technology
>> Phone: +1-630-303-7035
>> nsi...@nu...  http://www.nuemeta.com
>> Skype: nsincaglia

Re: [Exist-open] Fwd: Problem files after a crash

[Nick S. <nsi...@nu...>]

I found another example of this issue today. I had a file which was 
located here:
/db/apps/core/message-store/data/DEP-42/20210912/193872978031-20210912232055722.xml

My scripts would fail when they tried to process it. I took a backup of 
the database. Then I opened the file in Oxygen, clicked the Format and 
Index icon and then saved it. My scripts processed this file without any 
problem.

I have the database backup and would love to get some help in trying to 
explain what is wrong with this file or the indexes that is causing this 
problem.

Nick

On 9/27/21 9:07 AM, Nick Sincaglia wrote:
> Joe,
> I have experienced this issue on various different versions of 
> eXist-db. I don't think it is specific to the version I am using.
>
> I have a variety of different eXist-db versions running for different 
> clients. I usually try to get a new client using the latest version of 
> eXist-db when I first start working with them and unless there is a 
> good reason to upgrade, I usually keep them on that version for a 
> while. Every new version of eXist-db comes with the potential risk 
> that something that was working might break in the new version. So, I 
> am reluctant to upgrade unless it there is a clear benefit.
>
> The issue I described is caused by the initial crash. It is just not 
> clear to me why the re-index does not address the issue. It is hard to 
> find these files as well. Usually I find them because the system is 
> throwing an unexplained error. It would be helpful to be able to 
> detect these files after a crash to proactively identify them before 
> they cause the system to error in unexplained ways.
>
> Nick
>
> On 9/26/21 8:13 PM, Joe Wicentowski wrote:
>> Hi Nick,
>>
>> I don't have any suggestions, except perhaps one: Have you considered 
>> upgrading to eXist 5? It's got a lot of fixes to locking and has been 
>> very stable for us in production.
>>
>> Joe
>>
>> On Sun, Sep 26, 2021 at 5:57 PM Nick Sincaglia 
>> <nsi...@nu... <mailto:nsi...@nu...>> wrote:
>>
>>     I brought this up on the last community call but I wanted to send
>>     the e-mail to see if the wider community audience might have some
>>     suggestions.
>>
>>     I had my eXist-db v4.5 crash a number of weeks ago. I restarted
>>     the system, it ran through the data integrity check and
>>     everything seemed to be OK. However, later, I noticed one of the
>>     files in my system that was not indexed correctly. I could tell
>>     this because my file processing script could find the file in the
>>     system but I was getting an error that did not make any sense.
>>
>>     So, what I decided to do next was to reindex the entire database
>>     (xmldb:reindex('/db')). I tried running my script again and I
>>     still got the same error. So, next I located the file in the
>>     system, opened up the file and made a minor change to the XML
>>     file (The small change I made was I added a white space to the
>>     end of the file, but I could have made any change.) Then I saved
>>     the file. After that, I ran my script and everything worked as
>>     expected.
>>
>>     What I believe I understand about this issue is that there is
>>     something that happens when you save a file, which forces a
>>     re-index of a file, which is different then if you run
>>     xmldb:reindex(). Also, I have experimented with downloading a
>>     collection of documents, then deleting the collection in the
>>     database and then uploading the collection to the database using
>>     WebDAV. This technique also does not solve the issue. There is
>>     something about opening the file, changing it and then saving it
>>     that resolves this issue. I was posting this because I see this
>>     issue every 6 months or so. Whenever, I am completely stumped by
>>     a script not running properly, I have learned to locate the file,
>>     modify it in a minor way and resave it and very frequently it
>>     resolves my issue.
>>
>>     When I brought this up on the community call, I was given 2
>>     suggestions. First, they thought maybe the XML files had a BOM
>>     character in them. This is not the case for me because we are not
>>     working with any Windows servers. I have seen this BOM character
>>     issue before and so I can confidently say, this is not related to
>>     a BOM character.
>>
>>     The second suggestion was that maybe our index was indexing an
>>     attribute instead of a tag. I checked my index and I don't think
>>     this is the case. My index file is below.
>>     <collection xmlns="http://exist-db.org/collection-config/1.0"
>>     <http://exist-db.org/collection-config/1.0>>
>>         <index>
>>             <!-- Disable the old full text index -->
>>             <fulltext default="none" attributes="false"/>
>>             <!-- New full text index based on Lucene indexes for full
>>     names and song titles -->
>>             <lucene>
>>                 <analyzer
>>     class="org.apache.lucene.analysis.standard.StandardAnalyzer"/>
>>                 <analyzer id="ws"
>>     class="org.apache.lucene.analysis.WhitespaceAnalyzer"/>
>>             </lucene>
>>             <!-- Range indexes for fast ID lookups -->
>>             <range>
>>                 <create qname="next-activity" type="xs:string"/>
>>                 <create qname="data-exchange-id" type="xs:string"/>
>>                 <create qname="data-origin-party-id" type="xs:string"/>
>>                 <create qname="data-destination-party-id"
>>     type="xs:string"/>
>>                 <create qname="release-id" type="xs:string"/>
>>                 <create qname="search" type="xs:string"/>
>>                 <create qname="delivery-type" type="xs:string"/>
>>                 <create qname="queue-date-time" type="xs:string"/>
>>                 <create qname="delivery-date-time" type="xs:string"/>
>>                 <create qname="workflow-status" type="xs:string"/>
>>                 <create qname="event-timestamp" type="xs:dateTime"/>
>>             </range>
>>         </index>
>>     </collection>
>>
>>     Any thoughts or suggestions are welcome!
>>
>>     Nick
>>
>>     -- 
>>     Nick Sincaglia
>>     President/Founder
>>     NueMeta, LLC
>>     Digital Media & Technology
>>     Phone: +1-630-303-7035
>>     nsi...@nu...  <mailto:nsi...@nu...>  
>>     http://www.nuemeta.com  <http://www.nuemeta.com>
>>     Skype: nsincaglia
>>
>>     _______________________________________________
>>     Exist-open mailing list
>>     Exi...@li...
>>     <mailto:Exi...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/exist-open
>>     <https://lists.sourceforge.net/lists/listinfo/exist-open>
>>
>> -- 
>> Sent from my iPhone
>
> -- 
> Nick Sincaglia
> President/Founder
> NueMeta, LLC
> Digital Media & Technology
> Phone: +1-630-303-7035
> nsi...@nu...  
> http://www.nuemeta.com
> Skype: nsincaglia

-- 
Nick Sincaglia
President/Founder
NueMeta, LLC
Digital Media & Technology
Phone: +1-630-303-7035
nsi...@nu...
http://www.nuemeta.com
Skype: nsincaglia

[Exist-open] Fwd: Problem files after a crash

[Nick S. <nsi...@nu...>]

Joe,
I have experienced this issue on various different versions of eXist-db. 
I don't think it is specific to the version I am using.

I have a variety of different eXist-db versions running for different 
clients. I usually try to get a new client using the latest version of 
eXist-db when I first start working with them and unless there is a good 
reason to upgrade, I usually keep them on that version for a while. 
Every new version of eXist-db comes with the potential risk that 
something that was working might break in the new version. So, I am 
reluctant to upgrade unless it there is a clear benefit.

The issue I described is caused by the initial crash. It is just not 
clear to me why the re-index does not address the issue. It is hard to 
find these files as well. Usually I find them because the system is 
throwing an unexplained error. It would be helpful to be able to detect 
these files after a crash to proactively identify them before they cause 
the system to error in unexplained ways.

Nick

On 9/26/21 8:13 PM, Joe Wicentowski wrote:
> Hi Nick,
>
> I don't have any suggestions, except perhaps one: Have you considered 
> upgrading to eXist 5? It's got a lot of fixes to locking and has been 
> very stable for us in production.
>
> Joe
>
> On Sun, Sep 26, 2021 at 5:57 PM Nick Sincaglia <nsi...@nu... 
> <mailto:nsi...@nu...>> wrote:
>
>     I brought this up on the last community call but I wanted to send
>     the e-mail to see if the wider community audience might have some
>     suggestions.
>
>     I had my eXist-db v4.5 crash a number of weeks ago. I restarted
>     the system, it ran through the data integrity check and everything
>     seemed to be OK. However, later, I noticed one of the files in my
>     system that was not indexed correctly. I could tell this because
>     my file processing script could find the file in the system but I
>     was getting an error that did not make any sense.
>
>     So, what I decided to do next was to reindex the entire database
>     (xmldb:reindex('/db')). I tried running my script again and I
>     still got the same error. So, next I located the file in the
>     system, opened up the file and made a minor change to the XML file
>     (The small change I made was I added a white space to the end of
>     the file, but I could have made any change.) Then I saved the
>     file. After that, I ran my script and everything worked as expected.
>
>     What I believe I understand about this issue is that there is
>     something that happens when you save a file, which forces a
>     re-index of a file, which is different then if you run
>     xmldb:reindex(). Also, I have experimented with downloading a
>     collection of documents, then deleting the collection in the
>     database and then uploading the collection to the database using
>     WebDAV. This technique also does not solve the issue. There is
>     something about opening the file, changing it and then saving it
>     that resolves this issue. I was posting this because I see this
>     issue every 6 months or so. Whenever, I am completely stumped by a
>     script not running properly, I have learned to locate the file,
>     modify it in a minor way and resave it and very frequently it
>     resolves my issue.
>
>     When I brought this up on the community call, I was given 2
>     suggestions. First, they thought maybe the XML files had a BOM
>     character in them. This is not the case for me because we are not
>     working with any Windows servers. I have seen this BOM character
>     issue before and so I can confidently say, this is not related to
>     a BOM character.
>
>     The second suggestion was that maybe our index was indexing an
>     attribute instead of a tag. I checked my index and I don't think
>     this is the case. My index file is below.
>     <collection xmlns="http://exist-db.org/collection-config/1.0"
>     <http://exist-db.org/collection-config/1.0>>
>         <index>
>             <!-- Disable the old full text index -->
>             <fulltext default="none" attributes="false"/>
>             <!-- New full text index based on Lucene indexes for full
>     names and song titles -->
>             <lucene>
>                 <analyzer
>     class="org.apache.lucene.analysis.standard.StandardAnalyzer"/>
>                 <analyzer id="ws"
>     class="org.apache.lucene.analysis.WhitespaceAnalyzer"/>
>             </lucene>
>             <!-- Range indexes for fast ID lookups -->
>             <range>
>                 <create qname="next-activity" type="xs:string"/>
>                 <create qname="data-exchange-id" type="xs:string"/>
>                 <create qname="data-origin-party-id" type="xs:string"/>
>                 <create qname="data-destination-party-id"
>     type="xs:string"/>
>                 <create qname="release-id" type="xs:string"/>
>                 <create qname="search" type="xs:string"/>
>                 <create qname="delivery-type" type="xs:string"/>
>                 <create qname="queue-date-time" type="xs:string"/>
>                 <create qname="delivery-date-time" type="xs:string"/>
>                 <create qname="workflow-status" type="xs:string"/>
>                 <create qname="event-timestamp" type="xs:dateTime"/>
>             </range>
>         </index>
>     </collection>
>
>     Any thoughts or suggestions are welcome!
>
>     Nick
>
>     -- 
>     Nick Sincaglia
>     President/Founder
>     NueMeta, LLC
>     Digital Media & Technology
>     Phone: +1-630-303-7035
>     nsi...@nu...  <mailto:nsi...@nu...>  
>     http://www.nuemeta.com  <http://www.nuemeta.com>
>     Skype: nsincaglia
>
>     _______________________________________________
>     Exist-open mailing list
>     Exi...@li...
>     <mailto:Exi...@li...>
>     https://lists.sourceforge.net/lists/listinfo/exist-open
>     <https://lists.sourceforge.net/lists/listinfo/exist-open>
>
> -- 
> Sent from my iPhone

-- 
Nick Sincaglia
President/Founder
NueMeta, LLC
Digital Media & Technology
Phone: +1-630-303-7035
nsi...@nu...  
http://www.nuemeta.com
Skype: nsincaglia

[Exist-open] Problem files after a crash

[Nick S. <nsi...@nu...>]

I brought this up on the last community call but I wanted to send the 
e-mail to see if the wider community audience might have some suggestions.

I had my eXist-db v4.5 crash a number of weeks ago. I restarted the 
system, it ran through the data integrity check and everything seemed to 
be OK. However, later, I noticed one of the files in my system that was 
not indexed correctly. I could tell this because my file processing 
script could find the file in the system but I was getting an error that 
did not make any sense.

So, what I decided to do next was to reindex the entire database 
(xmldb:reindex('/db')). I tried running my script again and I still got 
the same error. So, next I located the file in the system, opened up the 
file and made a minor change to the XML file (The small change I made 
was I added a white space to the end of the file, but I could have made 
any change.) Then I saved the file. After that, I ran my script and 
everything worked as expected.

What I believe I understand about this issue is that there is something 
that happens when you save a file, which forces a re-index of a file, 
which is different then if you run xmldb:reindex(). Also, I have 
experimented with downloading a collection of documents, then deleting 
the collection in the database and then uploading the collection to the 
database using WebDAV. This technique also does not solve the issue. 
There is something about opening the file, changing it and then saving 
it that resolves this issue. I was posting this because I see this issue 
every 6 months or so. Whenever, I am completely stumped by a script not 
running properly, I have learned to locate the file, modify it in a 
minor way and resave it and very frequently it resolves my issue.

When I brought this up on the community call, I was given 2 suggestions. 
First, they thought maybe the XML files had a BOM character in them. 
This is not the case for me because we are not working with any Windows 
servers. I have seen this BOM character issue before and so I can 
confidently say, this is not related to a BOM character.

The second suggestion was that maybe our index was indexing an attribute 
instead of a tag. I checked my index and I don't think this is the case. 
My index file is below.
<collection xmlns="http://exist-db.org/collection-config/1.0">
     <index>
         <!-- Disable the old full text index -->
         <fulltext default="none" attributes="false"/>
         <!-- New full text index based on Lucene indexes for full names 
and song titles -->
         <lucene>
             <analyzer 
class="org.apache.lucene.analysis.standard.StandardAnalyzer"/>
             <analyzer id="ws" 
class="org.apache.lucene.analysis.WhitespaceAnalyzer"/>
         </lucene>
         <!-- Range indexes for fast ID lookups -->
         <range>
             <create qname="next-activity" type="xs:string"/>
             <create qname="data-exchange-id" type="xs:string"/>
             <create qname="data-origin-party-id" type="xs:string"/>
             <create qname="data-destination-party-id" type="xs:string"/>
             <create qname="release-id" type="xs:string"/>
             <create qname="search" type="xs:string"/>
             <create qname="delivery-type" type="xs:string"/>
             <create qname="queue-date-time" type="xs:string"/>
             <create qname="delivery-date-time" type="xs:string"/>
             <create qname="workflow-status" type="xs:string"/>
             <create qname="event-timestamp" type="xs:dateTime"/>
         </range>
     </index>
</collection>

Any thoughts or suggestions are welcome!

Nick

-- 
Nick Sincaglia
President/Founder
NueMeta, LLC
Digital Media & Technology
Phone: +1-630-303-7035
nsi...@nu...
http://www.nuemeta.com
Skype: nsincaglia

Re: [Exist-open] off-top: Fore - an alternative to betterFORM

[Alfredo C. <alf...@gm...>]

Hello Joern,
I tried to load the js by the cdn or from sigle local file, but I see only
a blank page.
Also the debugger in devTools doesn't show errors.
Thanks,
Alfredo

Il giorno lun 20 set 2021 alle ore 19:07 Joern Turner <
joe...@gm...> ha scritto:

> Alfredo,
>
> just add the file 'fore-all.js' from dist directory (you can build it
> yourself with 'npm run build')  and add it to your xar wherever you want
> it. Then just import it in an html page with
>
> <script type="module">
>     import 'resources/scripts/fore-all.js';
> </script>
>
> assuming you've put the file in the directory 'resources/scripts'.
>
> That should do it.
>
> Best,
>
> Joern
>
>
>
> On Mon, Sep 20, 2021 at 7:02 PM Alfredo Cosco <alf...@gm...>
> wrote:
>
>> Hi all,
>> After some advice received in this group I tested Fore. I managed to
>> install it locally, I have to admit that it is right for me but: I have no
>> idea how to make Fore work within my application in eXist.
>> Someone to tell me how to do?
>> Thanks,
>> Alfredo
>>
>>
>> Il giorno dom 19 set 2021 alle ore 08:13 Dannes Wessels <
>> di...@ex...> ha scritto:
>>
>>> Great work Joern,
>>>
>>> I can’t wait to get started with it!
>>>
>>> Thnx for sharing with the community!
>>>
>>> Cheers
>>>
>>> Dannes
>>>
>>> On 18 Sep 2021, at 12:54, Joern Turner <joe...@gm...> wrote:
>>>
>>> 
>>> Hi *,
>>>
>>> please excuse the off-topic here - not strictly eXist-db-related but
>>> might be of interest for those still using betterFORM and eXist-db:
>>>
>>> Fore is a pure client-side XFormish state-engine that uses vanilla
>>> JavaScript and Web Components to provide an alternative to betterFORM.
>>>
>>> It's still in beta and certainly does not cover everything that
>>> betterFORM does. However it requires much less setup and has no
>>> dependencies on eXist-db and in some areas even exceeds what betterFORM
>>> could do. Furthermore there are no restrictions any more regarding styling
>>> and use of custom controls which has been a pain with betterFORM sometimes.
>>>
>>> It has now come to a stage that already allows some serious use cases
>>> and I would be happy about any feedback, feature requests and so on.
>>>
>>> For further information please see https://github.com/Jinntec/Fore.
>>> Feel free to use the discussion board or contact me by mail for questions.
>>>
>>> Thanks for your interest.
>>>
>>> Joern
>>>
>>> _______________________________________________
>>> 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
>>>
>>

Re: [Exist-open] off-top: Fore - an alternative to betterFORM

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

btw guys - i'm happy if you would leave a 'star' on github. The project is
very new and this helps to grow a community - big thanks!

Not to forget - i'm happy to answer questions that are purely related to
Fore on its 'discussions' or 'issues' pages to not clutter this mailing
list with non-related emails. Thanks

On Mon, Sep 20, 2021 at 7:07 PM Joern Turner <joe...@gm...> wrote:

> Alfredo,
>
> just add the file 'fore-all.js' from dist directory (you can build it
> yourself with 'npm run build')  and add it to your xar wherever you want
> it. Then just import it in an html page with
>
> <script type="module">
>     import 'resources/scripts/fore-all.js';
> </script>
>
> assuming you've put the file in the directory 'resources/scripts'.
>
> That should do it.
>
> Best,
>
> Joern
>
>
>
> On Mon, Sep 20, 2021 at 7:02 PM Alfredo Cosco <alf...@gm...>
> wrote:
>
>> Hi all,
>> After some advice received in this group I tested Fore. I managed to
>> install it locally, I have to admit that it is right for me but: I have no
>> idea how to make Fore work within my application in eXist.
>> Someone to tell me how to do?
>> Thanks,
>> Alfredo
>>
>>
>> Il giorno dom 19 set 2021 alle ore 08:13 Dannes Wessels <
>> di...@ex...> ha scritto:
>>
>>> Great work Joern,
>>>
>>> I can’t wait to get started with it!
>>>
>>> Thnx for sharing with the community!
>>>
>>> Cheers
>>>
>>> Dannes
>>>
>>> On 18 Sep 2021, at 12:54, Joern Turner <joe...@gm...> wrote:
>>>
>>> 
>>> Hi *,
>>>
>>> please excuse the off-topic here - not strictly eXist-db-related but
>>> might be of interest for those still using betterFORM and eXist-db:
>>>
>>> Fore is a pure client-side XFormish state-engine that uses vanilla
>>> JavaScript and Web Components to provide an alternative to betterFORM.
>>>
>>> It's still in beta and certainly does not cover everything that
>>> betterFORM does. However it requires much less setup and has no
>>> dependencies on eXist-db and in some areas even exceeds what betterFORM
>>> could do. Furthermore there are no restrictions any more regarding styling
>>> and use of custom controls which has been a pain with betterFORM sometimes.
>>>
>>> It has now come to a stage that already allows some serious use cases
>>> and I would be happy about any feedback, feature requests and so on.
>>>
>>> For further information please see https://github.com/Jinntec/Fore.
>>> Feel free to use the discussion board or contact me by mail for questions.
>>>
>>> Thanks for your interest.
>>>
>>> Joern
>>>
>>> _______________________________________________
>>> 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
>>>
>>

Re: [Exist-open] off-top: Fore - an alternative to betterFORM

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

Alfredo,

just add the file 'fore-all.js' from dist directory (you can build it
yourself with 'npm run build')  and add it to your xar wherever you want
it. Then just import it in an html page with

<script type="module">
    import 'resources/scripts/fore-all.js';
</script>

assuming you've put the file in the directory 'resources/scripts'.

That should do it.

Best,

Joern



On Mon, Sep 20, 2021 at 7:02 PM Alfredo Cosco <alf...@gm...>
wrote:

> Hi all,
> After some advice received in this group I tested Fore. I managed to
> install it locally, I have to admit that it is right for me but: I have no
> idea how to make Fore work within my application in eXist.
> Someone to tell me how to do?
> Thanks,
> Alfredo
>
>
> Il giorno dom 19 set 2021 alle ore 08:13 Dannes Wessels <
> di...@ex...> ha scritto:
>
>> Great work Joern,
>>
>> I can’t wait to get started with it!
>>
>> Thnx for sharing with the community!
>>
>> Cheers
>>
>> Dannes
>>
>> On 18 Sep 2021, at 12:54, Joern Turner <joe...@gm...> wrote:
>>
>> 
>> Hi *,
>>
>> please excuse the off-topic here - not strictly eXist-db-related but
>> might be of interest for those still using betterFORM and eXist-db:
>>
>> Fore is a pure client-side XFormish state-engine that uses vanilla
>> JavaScript and Web Components to provide an alternative to betterFORM.
>>
>> It's still in beta and certainly does not cover everything that
>> betterFORM does. However it requires much less setup and has no
>> dependencies on eXist-db and in some areas even exceeds what betterFORM
>> could do. Furthermore there are no restrictions any more regarding styling
>> and use of custom controls which has been a pain with betterFORM sometimes.
>>
>> It has now come to a stage that already allows some serious use cases and
>> I would be happy about any feedback, feature requests and so on.
>>
>> For further information please see https://github.com/Jinntec/Fore. Feel
>> free to use the discussion board or contact me by mail for questions.
>>
>> Thanks for your interest.
>>
>> Joern
>>
>> _______________________________________________
>> 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
>>
>

Re: [Exist-open] off-top: Fore - an alternative to betterFORM

[Alfredo C. <alf...@gm...>]

Hi all,
After some advice received in this group I tested Fore. I managed to
install it locally, I have to admit that it is right for me but: I have no
idea how to make Fore work within my application in eXist.
Someone to tell me how to do?
Thanks,
Alfredo


Il giorno dom 19 set 2021 alle ore 08:13 Dannes Wessels <di...@ex...>
ha scritto:

> Great work Joern,
>
> I can’t wait to get started with it!
>
> Thnx for sharing with the community!
>
> Cheers
>
> Dannes
>
> On 18 Sep 2021, at 12:54, Joern Turner <joe...@gm...> wrote:
>
> 
> Hi *,
>
> please excuse the off-topic here - not strictly eXist-db-related but might
> be of interest for those still using betterFORM and eXist-db:
>
> Fore is a pure client-side XFormish state-engine that uses vanilla
> JavaScript and Web Components to provide an alternative to betterFORM.
>
> It's still in beta and certainly does not cover everything that betterFORM
> does. However it requires much less setup and has no dependencies on
> eXist-db and in some areas even exceeds what betterFORM could do.
> Furthermore there are no restrictions any more regarding styling and use of
> custom controls which has been a pain with betterFORM sometimes.
>
> It has now come to a stage that already allows some serious use cases and
> I would be happy about any feedback, feature requests and so on.
>
> For further information please see https://github.com/Jinntec/Fore. Feel
> free to use the discussion board or contact me by mail for questions.
>
> Thanks for your interest.
>
> Joern
>
> _______________________________________________
> 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
>

Re: [Exist-open] off-top: Fore - an alternative to betterFORM

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

Great work Joern,

I can’t wait to get started with it!

Thnx for sharing with the community!

Cheers

Dannes 

> On 18 Sep 2021, at 12:54, Joern Turner <joe...@gm...> wrote:
> 
> 
> Hi *,
> 
> please excuse the off-topic here - not strictly eXist-db-related but might be of interest for those still using betterFORM and eXist-db:
> 
> Fore is a pure client-side XFormish state-engine that uses vanilla JavaScript and Web Components to provide an alternative to betterFORM.
> 
> It's still in beta and certainly does not cover everything that betterFORM does. However it requires much less setup and has no dependencies on eXist-db and in some areas even exceeds what betterFORM could do. Furthermore there are no restrictions any more regarding styling and use of custom controls which has been a pain with betterFORM sometimes.
> 
> It has now come to a stage that already allows some serious use cases and I would be happy about any feedback, feature requests and so on.
> 
> For further information please see https://github.com/Jinntec/Fore. Feel free to use the discussion board or contact me by mail for questions.
> 
> Thanks for your interest.
> 
> Joern
> 
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

[Exist-open] off-top: Fore - an alternative to betterFORM

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

Hi *,

please excuse the off-topic here - not strictly eXist-db-related but might
be of interest for those still using betterFORM and eXist-db:

Fore is a pure client-side XFormish state-engine that uses vanilla
JavaScript and Web Components to provide an alternative to betterFORM.

It's still in beta and certainly does not cover everything that betterFORM
does. However it requires much less setup and has no dependencies on
eXist-db and in some areas even exceeds what betterFORM could do.
Furthermore there are no restrictions any more regarding styling and use of
custom controls which has been a pain with betterFORM sometimes.

It has now come to a stage that already allows some serious use cases and I
would be happy about any feedback, feature requests and so on.

For further information please see https://github.com/Jinntec/Fore. Feel
free to use the discussion board or contact me by mail for questions.

Thanks for your interest.

Joern

Re: [Exist-open] [ANN] JDBC Driver installation packages

[Loren C. <lor...@gm...>]

Hello Dannes,

Thank you for your feedback.  I am working on a set of wrapper functions that wrap around the SQL module functions.

I have merged the pull requests. I did not get emails from GitHub to perform pull requests.  I guess that I have been spoiled with enterprise GitHub. 🙂

Thank you,
Loren

> On Sep 16, 2021, at 10:37 AM, Dannes Wessels <di...@ex...> wrote:
> 
> Hi Loren,
> 
> Thank you for your contribution !
> 
> All packages contain an example xquery module with example code that have no relation with the drivers. Please could you either remove them or update them with some code examples ?
> 
> Additionally GitHub allows to upload “releases” , in this case this you can release. xar file that can be actually used by users;
> 
> I’d recommend to apply A Git tag and create a release xar, which can be deployed into the package service.
> 
> Finally there are already PRs, please review them and accept/decline them.
> 
> Cheers
> 
> Dannes
> 
>> On 15 Sep 2021, at 22:24, Loren Cahlander <lor...@gm...> wrote:
>> 
>> Announcing installable JDBC driver packages for eXist-db version 5.0.0+
>> 
>> https://github.com/eXist-db/exist-mysql-jdbc-driver <https://github.com/eXist-db/exist-mysql-jdbc-driver>
>> https://github.com/eXist-db/exist-postgresql-jdbc-driver <https://github.com/eXist-db/exist-postgresql-jdbc-driver>
>> https://github.com/eXist-db/exist-snowflake-jdbc-driver <https://github.com/eXist-db/exist-snowflake-jdbc-driver>
>> https://github.com/eXist-db/exist-mariadb-jdbc-driver <https://github.com/eXist-db/exist-mariadb-jdbc-driver>
>> 
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] [ANN] JDBC Driver installation packages

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

Hi Loren,

Thank you for your contribution !

All packages contain an example xquery module with example code that have no relation with the drivers. Please could you either remove them or update them with some code examples ?

Additionally GitHub allows to upload “releases” , in this case this you can release. xar file that can be actually used by users;

I’d recommend to apply A Git tag and create a release xar, which can be deployed into the package service.

Finally there are already PRs, please review them and accept/decline them.

Cheers

Dannes 

> On 15 Sep 2021, at 22:24, Loren Cahlander <lor...@gm...> wrote:
> 
> Announcing installable JDBC driver packages for eXist-db version 5.0.0+
> 
> https://github.com/eXist-db/exist-mysql-jdbc-driver
> https://github.com/eXist-db/exist-postgresql-jdbc-driver
> https://github.com/eXist-db/exist-snowflake-jdbc-driver
> https://github.com/eXist-db/exist-mariadb-jdbc-driver
> 
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

[Exist-open] [ANN] JDBC Driver installation packages

[Loren C. <lor...@gm...>]

Announcing installable JDBC driver packages for eXist-db version 5.0.0+

https://github.com/eXist-db/exist-mysql-jdbc-driver <https://github.com/eXist-db/exist-mysql-jdbc-driver>
https://github.com/eXist-db/exist-postgresql-jdbc-driver <https://github.com/eXist-db/exist-postgresql-jdbc-driver>
https://github.com/eXist-db/exist-snowflake-jdbc-driver <https://github.com/eXist-db/exist-snowflake-jdbc-driver>
https://github.com/eXist-db/exist-mariadb-jdbc-driver <https://github.com/eXist-db/exist-mariadb-jdbc-driver>

Re: [Exist-open] Tips for upgrading to eXist 5.3.0

[Joe W. <jo...@gm...>]

p.s. The version number for existdb-packageservice listed below was
incorrect. It should be "1.3.13 or higher," not "2.8.13 or higher."
Apologies for the error. The release notes on exist-db.org have been
updated accordingly.

On Sun, Aug 1, 2021 at 1:17 PM Joe Wicentowski <jo...@gm...> wrote:

> Greetings,
>
> In light of reports of some unexpected problems that users encountered
> when upgrading to eXist 5.3.0, we have added an advisory to the 5.3.0
> release notes: https://exist-db.org/exist/apps/wiki/blogs/eXist/eXistdb530.
> For your convenience, the content of the advisory is reproduced below. Some
> of the items had been in the original announcement, but we moved them all
> up to the top of the release notes to make them more prominent.
>
> We hope this helps folks better prepare for this very worthwhile upgrade
> and makes the upgrade process smoother.
>
> Joe
>
>
> - Before upgrading an eXist 5.2.0 or earlier system to eXist 5.3.0 (or as
> soon as possible after upgrading), be sure to upgrade
> *existdb-packageservice* to the latest release, version 2.8.13 or higher.
> Since Dashboard relies on this library for all package-related operations,
> this upgrade must be performed outside Dashboard. To upgrade this package
> outside of Dashboard, either submit the following query to eXist via eXide
> or the Java Admin Client as an admin user:
>
> xquery version "3.1";
>> repo:remove("http://exist-db.org/apps/existdb-packageservice"),
>> repo:install-and-deploy("http://exist-db.org/apps/existdb-packageservice",
>> "http
>> ://exist-db.org/exist/apps/public-repo/find")
>
>
> - The *shared resources* and *markdown* packages are no longer bundled
> with eXist-db. If your application depends on those you can still declare
> dependencies on them in your package metadata and download them from the package
> repository <https://exist-db.org/exist/apps/public-repo/index.html>.
>
> - *eXide*’s app generator function has been removed from eXide v3.0.0, as
> part of important improvements to the application. For generating apps,
> please use the much better yeoman-based generator-exist
> <https://github.com/eXist-db/generator-exist> tool.
>
> - *Dashboard* v2.0.8 has a known issue
> <https://github.com/eXist-db/dashboard/issues/194> that can cause
> requests a 404 error to appear after logging in to the administrative
> section. Until a permanent fix has been discovered, you can clear the
> affected browser of this problem by logging out and back in via eXide or
> Monex.
> The default eXist-db configuration settings are not production ready. Make
> sure to consult our article on best practices before making your eXist-db
> instance publicly available. The new existdb-config project implements
> these "best practices" and can easily be used to harden your eXist-db(s)
> from version 5.1.1 till 5.3.0.
>
> - The default eXist-db configuration settings are not production ready.
> Make sure to consult our article on best practices
> <https://exist-db.org/exist/apps/doc/production_good_practice.xml> before
> making your eXist-db instance publicly available. The new existdb-config
> <https://github.com/eXistSolutions/existdb-config> project implements
> these "best practices" and can easily be used to harden your eXist-db(s)
> from version 5.1.1 till 5.3.0.
>
>

Re: [Exist-open] Mail Module

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

Thanks Nick :-)

On Thu, 12 Aug 2021 at 07:10, Nick Sincaglia <nsi...@nu...> wrote:
>
> Adam,
>
> I was able to resolve the Mail module issue with eXist-db v5.3.0 by switching back to Java to 1.8.
>
> I think I will be able to test eXist-db v5.4.0-SNAPSHOT tomorrow. I will report back our results.
>
> Nick
>
> On 8/9/21 1:33 PM, Adam Retter wrote:
>
> Hi there,
>
> Would someone be able to test the Mail Module in eXist-db
> 5.4.0-SNAPSHOT? There is a nightly build available here -
> http://www.evolvedbinary.com/afterdark.html
>
> On Sun, 8 Aug 2021 at 21:12, Adam Retter <ad...@ex...> wrote:
>
> There is a small bug with the Mail Module in 5.3.0 that is now fixed. Expect a 5.4.0 very soon
>
> On Fri, 6 Aug 2021, 08:14 Michael Westbay, <wes...@ja...> wrote:
>
> Hi All,
>
> I'm currently working on moving one of my servers to eXist 5.3.0. When I went to 4.x a while back, the "http://exist-db.org/xquery/mail" module was still included, but it appears to be missing in 5.3.0.
>
> Am I missing it somewhere? Did I install it separately?
>
> --
> Michael Westbay
> Writer/System Administrator
> http://www.japanesebaseball.com/
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
>
>
> --
> Nick Sincaglia
> President/Founder
> NueMeta, LLC
> Digital Media & Technology
> Phone: +1-630-303-7035
> nsi...@nu...
> http://www.nuemeta.com
> Skype: nsincaglia
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open



-- 
Adam Retter

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

Re: [Exist-open] Mail Module

[Nick S. <nsi...@nu...>]

Adam,

I was able to resolve the Mail module issue with eXist-db v5.3.0 by 
switching back to Java to 1.8.

I think I will be able to test eXist-db v5.4.0-SNAPSHOT tomorrow. I will 
report back our results.

Nick

On 8/9/21 1:33 PM, Adam Retter wrote:
> Hi there,
>
> Would someone be able to test the Mail Module in eXist-db
> 5.4.0-SNAPSHOT? There is a nightly build available here -
> http://www.evolvedbinary.com/afterdark.html
>
> On Sun, 8 Aug 2021 at 21:12, Adam Retter <ad...@ex...> wrote:
>> There is a small bug with the Mail Module in 5.3.0 that is now fixed. Expect a 5.4.0 very soon
>>
>> On Fri, 6 Aug 2021, 08:14 Michael Westbay, <wes...@ja...> wrote:
>>> Hi All,
>>>
>>> I'm currently working on moving one of my servers to eXist 5.3.0. When I went to 4.x a while back, the "http://exist-db.org/xquery/mail" module was still included, but it appears to be missing in 5.3.0.
>>>
>>> Am I missing it somewhere? Did I install it separately?
>>>
>>> --
>>> Michael Westbay
>>> Writer/System Administrator
>>> http://www.japanesebaseball.com/
>>> _______________________________________________
>>> Exist-open mailing list
>>> Exi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/exist-open
>
>

-- 
Nick Sincaglia
President/Founder
NueMeta, LLC
Digital Media & Technology
Phone: +1-630-303-7035
nsi...@nu...
http://www.nuemeta.com
Skype: nsincaglia

Re: [Exist-open] Accidentally broke admin account

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

Hi Ian,

the restore option provides the option to pass 2 different passwords:

./bin/backup.sh —help
-p, --password <string>                    set the password for connecting to 
                                           the database.
                                           <string>: any string
                                           Default: 
-P, --dba-password <string>                if the backup specifies a different 
                                           password for the admin user, use this option 
                                           to specify the new password. Otherwise 
                                           you will get a permission denied
                                           <string>: any string
                                           Default: 

So I think you need to specify a password using -p and -P

regards

Dannes

--
eXist-db Native XML Database
http://www.exist-db.org



> On 28 Jul 2021, at 19:10 , Ian Davey <ia...@xc...> wrote:
> 
> Hello,
> 
> We were trying to migrate an eXist database to a new machine by backing up the relevant collections from the old one (using the Java admin client) and restoring them into the new one.  This has always run seamlessly when both the source and target databases have the same admin password, but when trying to restore into a database with a different admin password, it appeared to succeed, but now for some reason we are unable to log in as admin anymore.  Neither the source nor target password work.
> 
> We are running 5.3.0 on the target and 4.7.1 on the source.
> 
> Thanks,
> 
> 
> -- 
> Ian Davey
> Senior Engineer
> Xcential Corporation
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] index remains empty?

[Joe W. <jo...@gm...>]

Hi Eduard,

Without the full collection.xconf file it's hard to troubleshoot, but one
possibility is that the TEI namespace hasn't been declared in any ancestor
elements?

Joe

On Fri, Jul 30, 2021 at 7:13 AM Eduard Drenth <ed...@fr...>
wrote:

> Dear all,
>
> In exist 5.3.0 I have a range index defined:
>
> <create qname="tei:cit">
>     <field name="cit-type" match="@type" type="xs:string"/>
>
> </create>
>
>
> I see it back in monex, but... it is empty!
>
> What can be the problem?
>
> Regards, Eduard
>
> --
>
> 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 mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] Mail Module

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

Hi there,

Would someone be able to test the Mail Module in eXist-db
5.4.0-SNAPSHOT? There is a nightly build available here -
http://www.evolvedbinary.com/afterdark.html

On Sun, 8 Aug 2021 at 21:12, Adam Retter <ad...@ex...> wrote:
>
> There is a small bug with the Mail Module in 5.3.0 that is now fixed. Expect a 5.4.0 very soon
>
> On Fri, 6 Aug 2021, 08:14 Michael Westbay, <wes...@ja...> wrote:
>>
>> Hi All,
>>
>> I'm currently working on moving one of my servers to eXist 5.3.0. When I went to 4.x a while back, the "http://exist-db.org/xquery/mail" module was still included, but it appears to be missing in 5.3.0.
>>
>> Am I missing it somewhere? Did I install it separately?
>>
>> --
>> Michael Westbay
>> Writer/System Administrator
>> http://www.japanesebaseball.com/
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open



-- 
Adam Retter

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

Re: [Exist-open] eXistDB sequence generator?

[Gary <ga...@ra...>]

thanks Michael! 
  
This looks brilliant and I found the documentation here too: http://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/counter&location=java:org.exist.xquery.modules.counter.CounterModule 
  
I had written my own sequence generator but it has problems with persisting values, concurrency, with limit on counter to limit of java long, adjusting for customer counters and it creates so many additional requests outside exist... It is great to find something in eXist!   
  
   

-----Original Message-----

From: Michael <wes...@ja...>
To: Gary <ga...@co...>
Cc: exist-open <exi...@li...>; Gary <ga...@ra...>
Date: Monday, 9 August 2021 3:19 AM BST
Subject: Re: [Exist-open] eXistDB sequence generator?

 Oh, and one more thing about the counter module. You'll need to copy the counters file in your EXIST_DATA directory to any new instances you create. This is because it is NOT managed within the database itself, so not backed up or restored. But it should be fairly straightforward to create such a library module that is managed within the database. 
  
Take care.  
  2021年8月9日(月) 10:40 Michael Westbay <wes...@ja...>:  Hi Gary, 
  
See the "counter" module built into eXist. 
  
  
  let $dummy := counter:create('file-ids') 
  let $new-file-path := xmldb:store("/db/docs", concat(counter:next-value('file-ids'), '.xml'), $doc)   
  let $dummy := counter:destroy('file-ids')   
  
Hope this helps. 
  
Take care. 
   
  2021年8月9日(月) 2:44 Gary via Exist-open <exi...@li...>:  
   
Hi Guys, 
  
Is there an eXistDB sequence generator function I can use inside an XQuery? 
  
I would like to create documents from an XQuery along these lines. 
  
 
 
let $new-file-path := xmldb:store("/db/docs", concat(xmldb:sequence-generator(), '.xml'), $doc)    
  
I am looking for a way to safely set, reset and persist counters and create a series of unique document names from each time the query is run e.g. 1.xml, 2.xml 3.xml etc.  
  
 
Kind Regards 
Gary 
Solution Architect 
https://www.rapport.net 
https://assistive.care 
https://q.rip 
  
Rapport Network CIC 
Registered in Scotland: SC458540     _______________________________________________
Exist-open mailing list
Exi...@li...
https://lists.sourceforge.net/lists/listinfo/exist-open   
  -- 
 Michael Westbay
Writer/System Administrator
http://www.japanesebaseball.com/    
  -- 
 Michael Westbay
Writer/System Administrator
http://www.japanesebaseball.com/