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 00:52:49 GMT
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" / 
> "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?
> 
> 


Mime
View raw message