Re: TIP#308 Published: Tcl Database Connectivity (TDBC)

Twylite wrote:
(1) The DBI is complex. The comparative lengths of my example functions illustrate that clearly. If ::tcl::db::execute had a
mechanism to report the ordered list of columns returned this would
make "simple" development a lot easier (comparable to SQLite). This
change alone would also void my comments about error handling (at
least to some degree).

We hope that we can get so most of that gunk is hidden.

(2) The amount of error handling this DBI requires is significant - 4
nested error handlers. Other DBIs require 1 to 3. This level of
error handling detracts from my task of writing in functionality makes quality assurance more difficult.

Definitely. It's an early revision of this TIP I think, a place to start
the serious discussion from and not the thing that will get done at the
end. Not yet. :-)

(3) Taking variables from the current stack frame is a recipe for trouble, and makes writing logic like extract_report more complex and
slower (best case: [dict with ...]; worst case: foreach {name value} { set ... }) I would prefer to see execute take a dict; then it is at
least clear what variables you are (and are not) providing. Taking
variables from the stack without clearly indicating them _in Tcl
code_ (as opposed to another language like SQL) is a little to much
of a DWIM for my liking.

That's planned. It was one of the first things that was pointed out as a flaw. :-)

(4) Returning the columns as a resultset is a real pain. Rather make
the columns available as
4.a) a list of tuples; or
4.b) a list of column names, plus a function to get a dict of
information about the column (given its name)

Now you're just talking about how *I* would do it too. :-D

(5) The primitive function to retrieve a row needs to retrieve it as
a list, IM(NS)HO. This is the natural structure to represent ordered
data as retrieved from a DBMS, and avoids a bunch of overhead
involved in creating and then parsing out a dict.

No. That *really* screws with Tcl's value system.

(6) I am concerned by the number of ensembles that a simple query
must create (and clean up). This smells like a performance concern,
especially for a pure-Tcl implementation for a specific database.

Psst! Use an object!

(7) A SELECT operation is fundamentally different from other commands
that can be executed. This is clear for example when you read the
spec for "resultset rows", which does not provide a meaningful value
in the case of SELECT. How you query a resultset is thus dependant
on the operation that was requested, which can make creating generic
DB manipulation functions rather fun. Other DBIs have also struggled
with this problem.

Actually, it's not that clean. Apparently Oracle can return a result set
from non-SELECT statements if asked nicely. (Yes, this surprised me a
lot too.)

Donal.
.

Relevant Pages

  • Re: NaN handling
    ... how hard would it be to extract this functionality from it to add to ... Harder than just enabling fpectl. ... point error handling, knock yourself out. ... Does numpy's NaN handling only work within numpy functions, ...
    (comp.lang.python)
  • Re: is cool
    ... additional functionality is in order. ... if {[dict exists $stuff yadda binga]} { ... That, and the ability to search keys in a case-insensitive way, altho I recognise that could be problematic with UTF-8 keys. ...
    (comp.lang.tcl)
  • Re: Pythonic way for missing dict keys
    ... Jakub Stolarski wrote in ... add value to dict. ... I may be missing something but I think the 3 approaches are completely ... equivalent in terms of functionality. ...
    (comp.lang.python)