From derby-user-return-3029-apmail-db-derby-user-archive=db.apache.org@db.apache.org Fri Dec 16 21:11:27 2005 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 29749 invoked from network); 16 Dec 2005 21:11:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 Dec 2005 21:11:27 -0000 Received: (qmail 83577 invoked by uid 500); 16 Dec 2005 21:11:25 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 83554 invoked by uid 500); 16 Dec 2005 21:11:24 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 83543 invoked by uid 99); 16 Dec 2005 21:11:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Dec 2005 13:11:24 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [32.97.182.144] (HELO e4.ny.us.ibm.com) (32.97.182.144) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Dec 2005 13:11:23 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBGLB2xS021798 for ; Fri, 16 Dec 2005 16:11:02 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBGLB2b1093762 for ; Fri, 16 Dec 2005 16:11:02 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBGLB2IO019745 for ; Fri, 16 Dec 2005 16:11:02 -0500 Received: from [127.0.0.1] (DMCSDJDT41P.usca.ibm.com [9.72.133.58]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBGLB11J019702 for ; Fri, 16 Dec 2005 16:11:02 -0500 Message-ID: <43A32D67.50708@debrunners.com> Date: Fri, 16 Dec 2005 13:11:03 -0800 From: Daniel John Debrunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: Derby Discussion Subject: Re: single file database? References: <200512142155.24290.msegel@segel.com> <200512160845.45061.msegel@segel.com> In-Reply-To: <200512160845.45061.msegel@segel.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N > On Friday 16 December 2005 2:16 am, Roger Keays wrote: >On Wednesday 14 December 2005 6:39 pm, Roger Keays wrote: > >>If a developer uses Derby for storage this >>would get cumbersome. Zipping the derby DB >>directory is one approach, but that >>complicates application saves, crash recovery, >>etc. > >>That is what I had in mind. I read the Derby already offers read-only >>access to zipped files so thats already half way there right? Correct, Derby writes all its i/o through a virtual file system layer, represented by classes in the package org.apache.derby.io. There are three complete implementations of this api: - regular file system - using java.io.* files, mainly RandomAccessFile - Jar/Zip - database files archived into a jar archive, read-only. - Classpath - database files accessible as resources though the class path/loader, read-only There is one partial implementation in the code line: - http - database files accessible on a http server, read-only There is one implementation being worked upon: - an in-memory one, I think someone has posted an intial patch for this. One could try an implementation of this package that stored all logically defined files in a single o/s file. Not sure how easy it would be, jar file format is one option, but it doesn't lend itself to being updatable very easily. Mapping blocks in the single physical file into blocks in the logical file is another, hard problems here are block allocation and re-mapping blocks when files are deleted etc. If you want to continue, this discussion would be best on the developers' list. My itch (not that I'm working on this) would be instead to have more utilities around the jar file format, backup directly into a jar file format, create a read-write copy of a database from a jar file. I wonder if these utilities would address your needs? Dan.