Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
From: Michael Segel <msegel@segel.com>
To: "Derby Discussion" <derby-user@db.apache.org>
Subject: Re: Derby and portability
Date: Wed, 16 Nov 2005 19:36:42 -0600
User-Agent: KMail/1.8
References: <437B58A3.6010506@sun.com> <437B965A.6010800@Source-Zone.Org>
 <c25576af0511161340p4edd570ao134aa2c6e5f27705@mail.gmail.com>
In-Reply-To: <c25576af0511161340p4edd570ao134aa2c6e5f27705@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200511161936.42798.msegel@segel.com>

On Wednesday 16 November 2005 15:40, Myrna van Lunteren wrote:

I wasn't going to respond but...

Sorry to be a nit, but this isn't a bug.

Maybe this is one of my pet peeves, but just because Derby doesn't behave the 
way you think it should means that there is a "product defect". (A polite way 
to call something a "bug".)

Does anyone recall "big endian and little endian" issues?
Or am I dating myself cause everyone uses Intel these days? ;-)

You don't just copy a database and drop it on a new system and say voila! 
C'est un database! (Or is a database female?)

With any database (Ok, DB2 and Informix... ;-) you have to export the data 
then import the data on a new platform. Note: I'm talking about DB2 <-> DB2 
and IDS <-> IDS where you're changing the platform from Platform A to 
Platform B and the platform can be 
"Window/AIX/HP-UX/Solaris/Linux/Siemens-Nixdorf"... well you get the idea.
(Oh and lets not forget we're keeping the version of the software constant 
too. ;-)

So yes, DERBY IS PLATFORM INDEPENDENT. I guess if you wanted to make the 
database that Derby creates platform independent then you should be prepared 
to create a numeric string data type and then redo all of the built in 
functions and plan on a huge performance hit.

Perhaps, as a suggestion... could someone go through the Derby-xxx issues and 
categorize them in to "Product Defect" / "Unexpected Result" / 
"Wishlist/Enhancement".

Then under "Product Defect" rate the severity of the problem.
Does this make sense?

> I think we should claim platform independence in this regard. I think
> DERBY-588 is the only case where we've run into a db created on one
> platform not working elsewhere, and it's listed as a bug. If we don't
> expect platform independence in this regard, this would be an
> enhancement...But I don't think that is ok - so I filed it as a bug. (and
> an odd one it is too). Myrna
>
>  On 11/16/05, Rajesh Kartha <kartha@source-zone.org> wrote:
> > Not sure, but shouldn't the JIRA issue, DERBY-588, be considered when
> > we claim the portability of a Derby database.
> > Database created in zOS does not boot in Windows due to the encoding of
> > the service.properties file.
> >
> > http://issues.apache.org/jira/browse/DERBY-588
> >
> > -Rajesh
> >
> > Mike Matrigali wrote:
> > > Currently the on-disk format is platform-independent. I don't see
> > > any reason not to make a committment to that going forward.
> > >
> > > Oyvind.Bakksjo@Sun.COM wrote:
> > >> The Derby Project Charter (on the web site) states that it should be
> > >> "Pure Java", but it does not say anything about portability for
> > >> anything but the _code_.
> > >>
> > >> Can one, for example, safely assume that the on-disk database format
> > >> is platform-independent? I have read it somewhere, but I don't see it
> > >> in the charter, so do I have a guarantee that this is an invariant?

-- 
Michael Segel
Principal 
MSCC