db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Segel <mse...@segel.com>
Subject Re: Derby and portability
Date Thu, 17 Nov 2005 01:36:42 GMT
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

Mime
View raw message