Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <003d01c540a5$e037c520$1401a8c0@RPWS002>
From: "RPost" <rp0428@pacbell.net>
To: "Derby Development" <derby-dev@db.apache.org>
References: <1305661950.1113325338789.JavaMail.jira@ajax.apache.org>
 <425C1C25.9000106@gmail.com> <425C4C6C.7010501@sbcglobal.net>
 <001e01c54066$309a7d40$0200000a@lan>
Subject: Re: [jira] Created: (DERBY-218) Add Relaxed Durability option
Date: Wed, 13 Apr 2005 20:54:44 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> Dibyendu Majumdar wrote:
> From: "Mike Matrigali" <mikem_app@sbcglobal.net>
> >  From responses to Dan's original post on building a system with the
> > sync options disabled it seemed like there was enough response that
> > those options should be made available.  I admit I am worried because
> > this system can no longer guarantee recoverability.  It would be
> > interesting to know how people would use such a configuration.
>
> I agree with you that a database system without recoverability is useless.

One use for a database without recoverability is for data
warehousing/reporting.

The database used as a datamart needs to be created without error but once
created the core tables can be read-only. Other read/write tables will be
used for searches, match-engine results and temporary tables to support
report-ready processes. Loss of data in these tables would not be serious
since they start out empty at the start of a process anyway.