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 15:17:35 GMT
On Thursday 17 November 2005 02:45, Oyvind.Bakksjo@sun.com wrote:
> Michael Segel wrote:

>
> I know developers want to create applications and deploy them with
> pre-built databases on multiple platforms. For them, just the fact that
> "it seems to be working today" isn't good enough - they need a statement
> that this is a Derby feature they can rely on.
>
Well, yes. 
The crux is that the issue lies not within Derby, but within the JVM which is 
going to have vendor specific characteristics.

I did a check and found that Java.io.* classes write high order byte first for 
numeric values. Since we're dealing with a virtual machine this should be 
consistent across all platforms and should guarantee compatability.
[Note:  The only potential danger is if you're writing something to a file and 
you're on hardware that is natively "little-endian" and you're doing cross 
langugage app development. (This is actually easy to solve, but you need to 
be aware of the potential danger.)]

With respect to the mainframe, there is an issue of backwards compatibility.
I believe that the latest release of zOS does support Unicode. But you still 
have corporations running OS/390  and prior releases of zOS.  It may take 2-3 
years before some firms even consider migrating to Unicode on their 
mainframe, if at all.  Even mentioning USS to the big iron keepers makes them 
nervous... ;-)

The net net is that the cost of migrating from EBCDIC to Unicode on the 
mainframe is not going to be done overnight, nor will it be cheap.

My point is that while for the most part you have true platform independence, 
you will always have issue with the big iron... but again its the JVM and you 
can always take it up with IBM... ;-)

> Then they won't end up calling something a bug just because it doesn't
> behave the way they think it should. (They would call it a bug since it
> violates the Derby charter. ;o)

Ok... :-P 

Bug is such an over used term. 
But we have a larger issue at hand.
Looking at Derby's Jira, there are over 300 open issues. 

I did a quick scan and picked out a couple. 
DERBY-396,
DERBY-616,
DERBY-713 a clone of DERBY-47

Now which of these are bugs?
DERBY-396 asks for the addition of standardized ALTER support to tables.
Is this a bug because its saying that Derby doesn't comply with the ANSI 
standard? Is this a CRITICAL issue?

Then looking at DERBY-47 and DERBY-713.

This is a bug. This is critical. This is something that shouldn't be too 
difficult to fix.  (Why anyone would take an IN (xxx,yyy) and add the BETWEEN 
to make it a range is beyond me... Were this an actual commercial product, 
this would be a "drop everything and fix this" priority.

The point I'm trying to make is that if we look at JIRA there are over 300 
open issues and the classification of what is critical and what is a bug are 
subjective.

There needs to be guidelines.
While DERBY-616 may be a bug, I wouldn't call it critical.

This is important because for Derby to be a success, you need to have a 
realistic priority of what needs to be fixed or enhanced.

And while Scott may have volunteered to fix #396, there are some design issues 
which need to be addressed that go beyond the scope of this one entry. How 
are these being addressed? They clearly aren't bugs or feature requests...

Sorry for the long post, but I wanted to give some concrete examples of the 
importance in understanding what constitutes a bug... 


-- 
Michael Segel
Principal 
MSCC

Mime
View raw message