size on collection in the time (Marc)

> Hello Marc, > > sure, a replace should lead to a true replace, i.e. the old data will be > dropped. So this sounds like a bug, but it is difficult to replicate > from what you describe. > > Do you think it would be possible to make the issue reproducable, maybe > also with a smaller data set? Also, how exactly do you add documents or > do you also do any queries and maybe other updating queries? > > Cheers > Dirk > > On 09/02/2015 05:36 PM, Marc wrote: > >> Hi, >> I have a remark about the size of the files of a collection. >> We do a lot of updates (REPLACE) with an attributes index but without >> a text index. >> I see that the size of the files grows up in the time we arrive until >> 30Go until the limit of the filessytems quota. >> When I drop the collection and recreate it from the last version of >> the files the size was only 6Go. >> >> We will redo the test with the time, but I just want to know if the >> program clears the disk use when he does a REPLACE? >> >> Marc

From: Marc <Marc.Liste at free.fr> To: Dirk Kirsten <dk at basex.org> Cc: BaseX <basex-talk at mailman.uni-konstanz.de> Subject: Re: [basex-talk] (no subject) Message-ID: <55E7FE41.5080205 at free.fr> Content-Type: text/plain; charset=iso-8859-15; format=flowed I forgot to give this precision, we use the 7.9 version on this server. Marc Le 01/01/1970 01:00, a ?crit : > Hello Dirk, > We use a BaseX script (.xbs) with a list of REPLACE. > We try to investigate this point if this is reproducable or not. > If I find this problem again, I take a copy of the collection before to > delete her. > > Thank you for answer. > > Marc > Le 03/09/2015 09:52, Dirk Kirsten a ?crit : Hello Marc, > > sure, a replace should lead to a true replace, i.e. the old data will be > dropped. So this sounds like a bug, but it is difficult to replicate > from what you describe. > > Do you think it would be possible to make the issue reproducable, maybe > also with a smaller data set? Also, how exactly do you add documents or > do you also do any queries and maybe other updating queries? > > Cheers > Dirk > > On 09/02/2015 05:36 PM, Marc wrote: Hi, > I have a remark about the size of the files of a collection. > We do a lot of updates (REPLACE) with an attributes index but without > a text index. > I see that the size of the files grows up in the time we arrive until > 30Go until the limit of the filessytems quota. > When I drop the collection and recreate it from the last version of > the files the size was only 6Go. > > We will redo the test with the time, but I just want to know if the > program clears the disk use when he does a REPLACE? > > Marc End of BaseX-Talk Digest, Vol 69, Issue 5 *****************************************

> I confirm the problem : on another database (same data, same script.xbs, > different server), we have exactly the same problem : the database grows > each time the script is run. > > I'm going to prepare a test-case with small public data tonight.

> > > > Best regards, > > Christophe > > > > > Hello Dirk, > We use a BaseX script (.xbs) with a list of REPLACE. > We try to investigate this point if this is reproducable or not. > If I find this problem again, I take a copy of the collection before to > delete her. > > Thank you for answer. > > Marc > Le 03/09/2015 09:52, Dirk Kirsten a ?crit : > > Hello Marc, > > sure, a replace should lead to a true replace, i.e. the old data will be > dropped. So this sounds like a bug, but it is difficult to replicate > from what you describe. > > Do you think it would be possible to make the issue reproducable, maybe > also with a smaller data set? Also, how exactly do you add documents or > do you also do any queries and maybe other updating queries? > > Cheers > Dirk > > On 09/02/2015 05:36 PM, Marc wrote: > > Hi, > I have a remark about the size of the files of a collection. > We do a lot of updates (REPLACE) with an attributes index but without > a text index. > I see that the size of the files grows up in the time we arrive until > 30Go until the limit of the filessytems quota. > When I drop the collection and recreate it from the last version of > the files the size was only 6Go. > > We will redo the test with the time, but I just want to know if the > program clears the disk use when he does a REPLACE? > > Marc > > > > ------------------------------ > > Message: 4 > Date: Thu, 3 Sep 2015 10:01:05 +0200 > From: Marc <Marc.Liste at free.fr> > To: Dirk Kirsten <dk at basex.org> > Cc: BaseX <basex-talk at mailman.uni-konstanz.de> > Subject: Re: [basex-talk] (no subject) > Message-ID: <55E7FE41.5080205 at free.fr> > Content-Type: text/plain; charset=iso-8859-15; format=flowed > > > I forgot to give this precision, we use the 7.9 version on this server. > > Marc > Le 01/01/1970 01:00, a ?crit : > > Hello Dirk, > We use a BaseX script (.xbs) with a list of REPLACE. > We try to investigate this point if this is reproducable or not. > If I find this problem again, I take a copy of the collection before to > delete her. > > Thank you for answer. > > Marc > Le 03/09/2015 09:52, Dirk Kirsten a ?crit : > > Hello Marc, > > sure, a replace should lead to a true replace, i.e. the old data will be > dropped. So this sounds like a bug, but it is difficult to replicate > from what you describe. > > Do you think it would be possible to make the issue reproducable, maybe > also with a smaller data set? Also, how exactly do you add documents or > do you also do any queries and maybe other updating queries? > > Cheers > Dirk > > On 09/02/2015 05:36 PM, Marc wrote: > > Hi, > I have a remark about the size of the files of a collection. > We do a lot of updates (REPLACE) with an attributes index but without > a text index. > I see that the size of the files grows up in the time we arrive until > 30Go until the limit of the filessytems quota. > When I drop the collection and recreate it from the last version of > the files the size was only 6Go. > > We will redo the test with the time, but I just want to know if the > program clears the disk use when he does a REPLACE? > > Marc > > > > End of BaseX-Talk Digest, Vol 69, Issue 5 > *****************************************