db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: derby standards
Date Tue, 23 Aug 2005 18:39:58 GMT
I do want to make one point. In my opinion, the DRDA communication 
between client and server is purely an internal interface. It is not 
touched by our users and changing the underlying protocol would in no 
way impact the portability of applications written in Derby to other 
databases.  I think in the past the value of using DRDA is it allows the 
IBM unversal driver to work with Derby; when Derby was an internal DB at 
IBM this made a lot of sense.  My question is is this still a 
requirement for Derby as an Apache project?  At this point, I see no 
compelling reason to move away from DRDA, but if at some point it 
becomes clear it really is hamstringing us in some way, either in terms 
of performance, security or functionality, I'd like to understand where 
we as a community stand on this question.  Do we try to convince the 
Open Group to change DRDA every time we have an issue, or do we forge 
ahead with our own modifications even if they're non-standard?

I agree I am a little confused about the use of non-standard "industry 
standard" feature like SELECT FOR UPDATE.  Another one that comes to 
mind is the DESCRIBE mechanism that many databases have but which is non 



Rick Hillegas wrote:

> I'm afraid I'm having a hard time figuring out Derby's relationship to 
> what might be called standards. The following principles seem to be 
> regularly advocated:
> 1) Derby should avoid inventing its own syntax and apis.
> 2) Instead, Derby should adopt syntax and apis endorsed by the 
> following authorities:
>  - ANSI SQL 2003
>  - JDBC 4.0
>  - JSRs
>  - Other Apache projects
> From time to time, other authorities are recommended even though they 
> conflict with principle (2):
> 3) Non-ANSI syntax used by popular databases like Oracle, DB2, 
> Postgres, and MySQL.
> 4) Constraints imposed by DRDA.
> Principle (3) proves to be particularly nettlesome since the popular 
> databases often disagree. As we expand Derby, I would like to 
> understand how we reconcile these principles. Perhaps, first, we 
> should state what Derby hopes to gain by compliance. The following 
> benefits might apply:
> A) Familiar syntax and apis encourage developers to use Derby for new 
> embedded applications.
> B) Compatible syntax and apis encourage migration of old applications 
> to Derby from other databases.
> C) Compatible syntax and apis make it easy to scale up usage of a 
> Derby-developed application by migrating it to an enterprise-calibre 
> dbms.
> With four popular databases to keep in mind, benefits (B) and (C) seem 
> hard to satisfy. I am worried that we are in danger of building a 
> database which does not deliver any of these benefits. I would like to 
> see us clarify our goals and compliance policies.
> Cheers,
> -Rick

View raw message