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 <[EMAIL PROTECTED]> 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.
[EMAIL PROTECTED] 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?
