db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Andersen <Lance.Ander...@Sun.COM>
Subject Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Date Fri, 10 Jul 2009 17:41:07 GMT

On Jul 10, 2009, at 10:47 AM, Kathey Marsden wrote:

> Lance Andersen wrote:
>>> 3) Does this create a slippery slope for violation of our  
>>> standards based charter?
>>
>> I do not see how.  Every database vendor has their own extensions  
>> which are above and beyond standards....
>>
> Such a  liberal approach to extensions would certainly require a  
> change to our charter which specifically states migration to other  
> databases as a reason for our standards adherence.

Being standards based does not necessarily mean you cannot have  
extensions, nor does  stating our charter is standards based have  
complete meaning.

For example, there are many  optional features  described by the SQL  
Standard just like there is for JDBC.  Derby certainly is not  
supporting all features in the JDBC or the latest SQL standard (nor  
does any other DB).  So even if you support a feature in a standard,  
it does not mean you can migrate a Derby application to a database  
which does not support that feature, meaning you have non-standard  
standards :-)

Most of the databases have been around long before the SQL Standard.   
Some databases have added features supported by other databases to aid  
in migration (such as in this case with TOP/LIMIT) because the feature  
is popular.  This can be more important that just deciding that every  
feature must be in a spec.

Do not get my wrong, standards are important (I am a spec lead and an  
alternate on the SQL standard committee), but should not be the only  
factor which decides whether something is worthwhile to add to your  
product.

Looking at the Derby charter, it just talks about standards which is  
at a high level.  It is not specific about levels of compliance or  
which versions of standards.  Also from time to time, standards remove  
a feature so must you immediately drop it from your product?  Of  
course not.

A balanced approach is best especially when at the value of the feature.

>>
>> When JDBC 4.1 completes the escape syntax will be there as we  
>> closed on this ages ago in the EG.  Regardless of the fact, it is  
>> Escape syntax to provide a standard way for JDBC apps to utilize  
>> the varying functionality in the ways different DBs provide support  
>> for this feature.
> If this doesn't require interface changes and if the JDBC committee  
> can publish the syntax  and guarantee it will be there and not be  
> changed for 4.1, I think it would be ok to implement this now at  
> least for the embedded driver. (The client might be harder).  We  
> could just leave it out of our documentation and have a Wiki pointer  
> to the JDBC spec draft.

It is escape syntax to allow the equivalent of LIMIT to be done in a  
portable way.  Derby could do this today with the windowing feature  
and this really has nothing to do with requiring JDBC syntax for what  
we are talking about.  My point for mentioning the JDBC escape syntax  
was that there are enough vendors with this type of functionality, it  
is worth adding to Derby in a fashion easier than using windowing...


> Kathey
>


Mime
View raw message