[Tcl-tdbc] Profiles: the Route Beyond Basic TDBC v1

[Donal K. F. <don...@ma...>]

Hi everyone

A while ago (well, probably on October 18 if the log's metadata is 
accurate) I was discussing with Kevin whether it would be possible to 
add a feature to TDBC (in essence, it was finding out the identity of 
the row just added) and he told me that it was not possible because some 
databases - or maybe more accurately some access interfaces - did not 
support it. The full log (stripped of the wholly irrelevant other 
conversations that were ongoing at the time) is attached.

As you can see from the log, my thoughts turned to how it would be 
possible to lift TDBC up above the basic lowest-common-denominator 
level. Now I'm not at all proposing that we should force databases to 
support the features that we want to see; I actually assume that that's 
impossible (OK, an oversimplification for open-source DBs, but a 
reasonable first approximation). Instead, what I want to do is to have a 
mechanism whereby a script can find out - in a standard way - what extra 
stuff is supported over and above the TDBC base.

My idea (borrowed from "standards space") is that of a "profile", which 
is a standardized way of going beyond a base level of a standard. The 
basic concept is that there are chunks of functionality that are 
commonly supported across many DBs but not all, and that where these 
things are supported, they should be done so in the same way (or not at 
all if the profile is not supported). However, this is not just a matter 
of "everyone do the same extra methods".

The (slightly) awkward thing is that it's useful for code to be able to 
discover what profiles are supported. In particular, there needs to be a 
method (either on the connection object or the class object that 
manufactures the connection, depending on whether people believe 
profiles are a property of the DB or the TDBC driver respectively) that 
returns the list supported profiles; with that, user code can easily ask 
what are supported. Then every defined profile needs to define a name, 
and user code can just do, say:

   if {$PROFILE_NAME in [$conn supportedProfiles]} {
       ... etc. ...
   }

Note that profiles are deliberately distinct from the introspection 
system. This is because introspection only reveals the interface to a 
class, and not whether some defined semantics are supported. It's not my 
intention for this mechanism to constrain what profiles do other than in 
the area of being self-described as outlined. (A profile could introduce 
a new method, many of them, or even none - e.g., if it happens to be 
doing things like constraining the SQL dialect - and this can apply 
anywhere throughout the TDBC system.) I'd suggest that baseline TDBC 
also be listed in the profile list, but that's definitely optional from 
my perspective. I suppose this also gives a way to handle evolution of 
the required parts of TDBC, but that's strictly outside the scope of 
this modest proposal.

I suggest this here because I would like feedback from other people on 
whether this is a good idea. (If people want, I can also rework this 
message into a TIP, but I don't really think that's necessary for TDBC.)

Donal.