db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject Re: Derby and portability
Date Thu, 17 Nov 2005 05:27:57 GMT
Michael Segel wrote:
> On Wednesday 16 November 2005 18:52, Jean T. Anderson wrote:
> Uhm actually Unicode is dealing with character sets.

> I was looking at how numeric values were stored.

oops, my apologies, I keyed on the word "string" and got off on a 
complete (odd) tangent about Unicode.

> When you output numeric values to a file, what is its raw representation? Is 
> an int an int or the byte code representation of the int?

I'm going to have to call on the Java and Derby internals experts to 
answer how values get physically stored in the files that make up a 
Derby database.

> Now if both of your systems are little Endian, then you shouldn't  have a 
> problem....

It doesn't matter for Derby. You can copy Derby databases between 
machines, and different architectures, without having to export/import 
the data. It's one of the features that make it incredibly easy to 
deploy Derby databases.

But, as Dan pointed out, this didn't get documented, so it isn't 
surprising that this isn't well known.


>>Michael Segel wrote:
>>>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?)
>>Actually, yes, with Derby you can copy a database and drop it on another
>>system. The database files themselves are platform independent and may
>>be moved between architectures. The joy of Unicode.
>>So, you can create a Derby database on Linux, zip up the database dir,
>>unzip on Windows and it does work. Unzip the same database files on
>>Solaris. I do this a lot.
>>However, one must be careful to tar, zip, or jar up the entire database
>>directory hierarchy.
>>>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. ;-)
>>You do not have to export/import a Derby database to move it between
>>platforms. It's a big, winning feature of Derby.
>>>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.
>>The Derby database files themselves *are* platform independent. The joy
>>of Unicode.
>>  -jean
>>>Perhaps, as a suggestion... could someone go through the Derby-xxx issues
>>>and categorize them in to "Product Defect" / "Unexpected Result" /
>>>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.
>>>>>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
>>>>>>>"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
>>>>>>>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?

View raw message