continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Venisse" <emmanuel.veni...@gmail.com>
Subject Re: New feature: Scheduled purge of old build results
Date Fri, 28 Mar 2008 17:29:50 GMT
On Fri, Mar 28, 2008 at 6:05 PM, Olivier Lamy <olamy@apache.org> wrote:

> 2008/3/28, Emmanuel Venisse <emmanuel.venisse@gmail.com>:
> > On Fri, Mar 28, 2008 at 4:44 PM, Wendy Smoak <wsmoak@gmail.com> wrote:
> >
> >  > On Fri, Mar 28, 2008 at 8:31 AM, Emmanuel Venisse
> >  > <emmanuel.venisse@gmail.com> wrote:
> >  >
> >
> > > >>               URL: http://jira.codehaus.org/browse/CONTINUUM-1696<
> http://jira.codehaus.org/browse/CONTINUUM-1696>
> >
> > >
> >  > > We must discuss about it.
> >  >
> >  > Okay. :)  Do you have a concern about adding this feature, or ... ?
> >  >
> >
> >
> > :)
> >
> >  I'd want to know what you mean with a purge.
> >  If you just delete old build results in the db, I don't think it will
> be
> >  enough.
> >  It will be better to keep somewhere (in a file) some datas about
> deleted
> >  build results so they will can be included in some historical graphs
> when
> >  we'll add them.
> >
> >  At the same time, I'd like to move build results out of the db because
> build
> >  results use lot of memory with all scm informations. If we want to keep
> some
> >  build results informations in the db for some requests, we need only
> some
> >  basic datas ( start/end dates, duration, build number, state) and
> >  dependencies changes. All others informations are statics and we don't
> need
> >  them for requests, only for the build result page. Before to implement
> the
> >  purge, I think it would be better to implement this to save memory
>
> totally Agree
>
> >. Then the  purge process will be:
> >  - remove the build result information file
> >  - remove the basic build result record in the db
> >  - create a new file for the history with data that was in the record.
> >
> >  WDYT?
> >
> >
> >  Emmanuel
> >
> Fine  (but we will create some files too which need a purge system too ?
> ;-))


Maybe we'll can choose in the purge system to purge history or not

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message