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
