Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: pass (athena.apache.org: domain of emmanuel.venisse@gmail.com
 designates 209.85.146.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=bp1ABLtUIXavjdMcsJna+S/PA3xd7YC9PziA8t2tZIklVhg8/3BD3peaCXSCxMfHHjjzIgyrW5TevpfFUAO1iNllZIpES9xIICIaUUP3Gsf6sTueYR1Cym3ix4XXVr1KRR4c7pVqfdhN3B8L0lEVc1QDQpkRABvTaWKndsd5okQ=
Message-ID: <f345f3480803280950p5d6dbcf0q8e1a4bffd47da1b5@mail.gmail.com>
Date: Fri, 28 Mar 2008 17:50:56 +0100
From: "Emmanuel Venisse" <emmanuel.venisse@gmail.com>
To: dev@continuum.apache.org
Subject: Re: New feature: Scheduled purge of old build results
In-Reply-To: <adba96190803280844k3332e7e9qeff05ac352970c85@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_33340_14998190.1206723056617"
References: <adba96190803280844k3332e7e9qeff05ac352970c85@mail.gmail.com>

------=_Part_33340_14998190.1206723056617
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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. 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

------=_Part_33340_14998190.1206723056617--