Re: TIP #308: Twylite's concerns
- From: Twylite <twylite.crypt@xxxxxxxxx>
- Date: Sun, 18 Nov 2007 23:59:18 -0800 (PST)
On Nov 17, 10:00 pm, Kevin Kenny <kenn...@xxxxxxx> wrote:
OK, so we start needing like [$db execute $sql -columns colsVar etc...]
That's easy enough to add; I can throw that in for the next round.
Sounds about right. I'm thinking that this execute is starting to
take a lot of arguments, and an -option/value approach may feel nicer.
e.g. tcl::db::execute dbHandle -sql required_sql_stmt -params
optional_dict_or_use_locals -nullvalue optional_null_substitute ...
You could also provide -variable and -script, or leave them out to get
a list-of-lists returned ;)
I'll do some thinking about this and propose an uber-function that
will solve world poverty, etc ;)
> (2) The amount of error handling this DBI requires is significant -
If, as you say, the simple change of adding a place for [$db execute]
to return the column list fixes this, I'm not going to address it
for now. Feel free to follow up if you have further issues.
I think I can live with this ;) I would like to see it addressed
before the TIP is finalised as catch {} has horrible performance
implications.
> (3) Taking variables from the current stack frame is a recipe for
The latest edits to TIP #308 allow for both versions. They are
I like this solution - best of both worlds.
> (4) Returning the columns as a resultset is a real pain. Rather make
> the columns available as
I'll think about this one a little bit. You're right that it's
most natural to the user to have it as list-of-tuples, and
that's easy to provide. It also seems more natural to the
database implementor to provide it as a result set, because it's
likely the result of a query against a system catalog. Probably
this is a spot where a little more glue is needed, to give both
sides of the interface their natural representation of the data.
I know I suggested list-of-tuples, but a list-of-names really is the
most common use of this information, so for reasons of (performance,
elegance, etc) I feel that the ordered list of names should be the
primitive. Not sure what to build around that to retrieve the other
information though, will do some thinking.
> (5) The primitive function to retrieve a row needs to retrieve it as
> a list, IM(NS)HO.
I address this point in a separate message, and still consider it
an open item.
Reply likewise separate.
> (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.
Essentially, it's three: the database connection (which likely
persists, and likely has a fixed name), the statement, and the result
set. Given the fact that database drivers are free to overload [$db
execute] (and in so doing, eliminate the need for the statement and
result-set handles), and given that performance-critical applications
are likely to want the explicit statement handles anyway (because of
the gains achievable with prepared statements), do the tweaks to the
'execute' functionality that you discussed above address this concern?
This is more of a concern about the use of ensembles than of splitting
the process into db -> statement -> resultset (which is, I agree,
completely necessary). Doesn't the use of ensembles/objects have a
far higher performance overhead than returning a data handle which is
queried by a function (like pgintcl's pg_result), especially when
those ensembles are short-lived (in particular the resultsets)?
If the concern is instead a general one with the "noun-verb" syntax of
[$handle command], I'd say, "it works for widgets, why shouldn't it
work for database connections?" This style has been around as long as
Tk has. While I agree that it remains controversial, I'd classify
under, "you can't please everyone."
Point conceded. All objects in Tcl (whatever OO system) will work as
noun-verb syntax, so coding and QA approaches will have to deal with
it.
> (7) A SELECT operation is fundamentally different from other
What's even more fun is that some things do both: Oracle's "UPDATE
... RETURNING ..." is a case in point. In any case, the 'statement'
and 'result set' interfaces proposed in the TIP are rather spare: it's
not immediately obvious to me that having separate 'exeute query' and
'execute update' functions will actually simplify things.
Erk! I knew there was a reason I avoided Oracle ;) Okay, sounds like
having a separate "query" doesn't buy anything.
Summary:
- [$db execute] needs an option to store a column list, and could be
more generic.
- Column names should be directly available from the resultset as a
list.
- Concern about performance implications of representing resultsets as
ensembles/objects; both because of ensemble create/teardown overhead,
and additional error handling levels & complexity.
Regards,
Twylite
.
- References:
- TIP#308 Published: Tcl Database Connectivity (TDBC)
- From: Donal K. Fellows
- Re: TIP#308 Published: Tcl Database Connectivity (TDBC)
- From: Twylite
- TIP #308: Twylite's concerns
- From: Kevin Kenny
- TIP#308 Published: Tcl Database Connectivity (TDBC)
- Prev by Date: Re: When [exit] won't exit
- Next by Date: Re: TIP#308 Published: Tcl Database Connectivity (TDBC)
- Previous by thread: TIP #308: Twylite's concerns
- Next by thread: Re: TIP#308 Published: Tcl Database Connectivity (TDBC)
- Index(es):
Relevant Pages
|
