Re: TDBC documentation, examples, syntax?

On Mar 16, 2:37 am, dkf <donal.k.fell...@xxxxxxxxx> wrote:
On 16 Mar, 04:52, "tom.rmadilo" <tom.rmad...@xxxxxxxxx> wrote:

Unfortunately the TDBC API, being a single level API, changes for
every driver and provides no opportunity for abstraction.

Maybe it isn't important for you to be able to reuse the same code
regardless of datasource. The API which I propose is similar to a
procedural API, the internal details are opaque, the interface remains
fixed.

That was actually a non-goal, or perhaps even an anti-goal. TDBC aims
to expose the underlying database's interpretation of SQL, for better
or for worse, because this at least does not prevent anyone from using
that database. Making all databases work the same... even with that
ISO spec mentioned earlier in this thread, it's not happening in a
hurry. (Most of the time when I have seen such attempts, they've
tended to work by doing "select * from table" and then manipulating
everything on the client side; not a very scalable approach!) Indeed,
during the planning stage for TDBC we solicited for input from
database extension authors and their strong feedback was that
retaining DB-specific quirks was desirable.

To put it another way, TDBC is about improving how Tcl interfaces with
databases so that at least some of the hard work for users is removed.
In particular, it's about spreading best-practices from one DB-
interface extension to the rest. It doesn't address how that maps to
the CLI precisely to permit the use of database-specific efficient
interfaces behind the scenes. (For example, it does not mandate the
use of prepared statements precisely because not all databases support
them - alas - but they are an extremely good implementation choice;
where not supported, the driver instead has to do *correct* quoting
internally. Users should not see the difference either way.) Efficient
back-end interface usage is encouraged; there probably needs to be a
wiki page or article written on this now that some experience has been
gained.

I guess my main complaint is that you misuse the term "driver". A
database driver is a piece of software which is provided by the
database vendor. Generally developers write client code which
interfaces with the driver API, such code is know as an SQL Client.
Drivers accept input which is well defined. They do whatever they do
to the input before they transmit the result to the SQL Server. Nobody
can require a database driver to "do" anything, including quoting.
This important job must be handled by the SQL Client, which links to
the driver. Sometimes drivers can expose a particular interface like
CLI or ODBC. These are external requirements and are unrelated to
whatever transforms the driver applies to the input before
transmitting the result to the SQL Server.

I agree that client side manipulation is VERY BAD! This is why I have
no mercy for the requirement of, for instance, the foreach feature.

But lets go back to the driver. A driver exposes an upper level API,
the API which is used by the client. The lower level API is opaque.
The database vendor which produces the driver has a choice: provide a
standard API, or provide a quirky API with non-standard features. The
standard API is an API which is shared, so that an SQL Client which
matches the standard API can link with any driver which exposes the
same API. This is the benefit of using a standard API. Standard APIs
are not a conspiracy to deprive users of the full benefits of the
quirky API, they are an agreement to use standardized terminology at a
particular point: the driver/client interface. The tension is between
vendors which want to provide cool quirky features and those which
want to provide standard interoperability.

Every API layer provides an opportunity to resolve quirks, but at some
point quirks need to reside outside of the standard API. Maybe you
think that TDBC should celebrate quirks instead of resolving or
isolating them from the main API. Okay, great.

There are lots of bad practices invented by database extension
authors. They usually make the mistake you have identified:
manipulation of a result set. This is the first indication of disease:
thinking that you can do something better in your local environment
than it can be done in the database. That is why my proposed API
offers no chance to manipulate a result set.
.

Relevant Pages

  • Re: Digital-tv card drivers and API discussion
    ... Designing completely new api takes some time and I ... > driver development experience, I have a couple of questions for you. ... > 2) As linux kernel is GPL-licensed, I cannot just port the linux driver ... I'm able to watch DVB programs converted from MPEG TS substreams to MPEG ...
    (freebsd-arch)
  • Re: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOLs
    ... distribution will call us and require intense support. ... profits with Linux sales - and 99.99 % of our income with Windows sales. ... I do not see the licensing issue of a stable kernel API where venders ... Our driver is GPL so there should no be a licensing issue. ...
    (Linux-Kernel)
  • Re: checking and Copying a file when system is Loading
    ... DAT files will work only for the Object ... you can definitely do it from the driver. ... user mode DLLs and in the most cases can use any API ... functions like an ordinary app. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: OGL portability and future delivery
    ... it could be a severe impact against OpenGL. ... DirectX is no standardized API. ... DirectX 10 relies on the Windows Driver Model. ...
    (comp.graphics.api.opengl)
  • Re: 3vl 2vl and NULL
    ... > or API to the stored data is of primarily interest to me. ... >> designers are capable of defining the world for application programmers, ... I am more of an end-user (aka developer) looking to those ... But building an enterprise database is a lot more than succeeding at a lot ...
    (comp.databases.theory)