On 12/19/2012 04:25 PM, Karl Lehenbauer wrote:
* It should probably be rewritten around the TDBC package. This
would simplify its future maintenance and it would hand on to TDBC
the support for the dependencies it has now on various DBMS
connectors. Most Tcl programmers would probably prefer TDBC for any
new application
Does anybody still use DIO? I think that it is overall pretty good
stuff except there is too much computational overhead in its
implementation.
I've been using it in the last month to do a project. It didn't required
intensive and demanding DBMS interaction, just managing a relatively
small dataset. I would be happy to keep this code compatible with future
releases of Rivet. I don't use some rather special feature of DIO such
as autokeys (which I failed to understand initially and never got
bothered trying to understand them later on). So I'm confident I could
wrap TDBC around the basic DIO interface to provide at least a partial
compatibility layer for the basic calls.
FlightAware uses FA-wrapped, native Pgtcl interfaces to PostgreSQL's
C library, libpq. pg_select in particular gets a thorough workout.
I haven't reviewed or used TDBC, but I am happy with Pgtcl's
tclishness (pg_select works a lot like foreach, for instance, and
obviates mucking around with result handles), its deep access to
PostgreSQL client/server capabilities such as asynchronous requests,
partial results, etc, which probably don't have a meta analogue, and
the powerful but little known sc_postgres package in Pgtcl that
generates and performs SQL inserts and updates from arrays and lists,
converts between epoch times and SQL dates and times, etc. I mention
this mostly to point to that native interfaces will almost always
integrate more deeply than a generalized wrapper and that FA is
unlikely to move away from this, other than perhaps for a wee bit of
mysql that is forced on us.
* I propose to rename the package as AIDA: Agnostic Interface to
Database Access
Is it possible to just use TDBC or does there need to be an
additional layer or what.
I don't see why we couldn't use TDBC
- Session package
* Rewrite it and make it TclOO and TDBC based. There are several
cases where you would like sessions to interact with the
application code in a flexible way. Mixins would come handy in
these cases avoiding the all too rigid subclassing
Fine with me. Although I consider the session package stable and
useful, we (FlightAware) have our own fairly intense custom session
stuff, so I certainly haven't given it a heavy workout.
Does your custom session code bear some suggestions for reworking and
improving Rivet's own Session package?
- Core
* Review commands interacting with arrays and consider to support
dictionaries wherever possible (on tclcore someone even put forward
the idea of dropping arrays support in Tcl9)
I am not a big fan of dicts. I think they fail to solve Tcl's data
representation shortcomings in a convincing,
smoothly-integral-to-the-language manner, and there are what seems to
me fairly simple data structures that are either unrepresentable in
dicts or require kludging. Not sure you agree? Try comparing
accessing / manipulating / walking the DOM in Javascript versus doing
it in Tcl.
Oh no I agree about the problem with certain data structure
representation...but dicts have been out there for quite several years
and we have calls to DIO that return results as lists or arrays or
strings....why not dicts that can be passed around as values?
::rivet::inspect is an example as the configuration database can be
comprehensively be represented like a tree rather than simply a flat
array (having Server, Dir and User sections).
As an expoeriment recently I tried to develop a prototype of framework
using just dicts as object instance representations and namespace
ensembles as object manipulators/interfaces. It was like an exercise I
gave myself. It worked quite well at first until I tried to combine
object instances into containers like lists. The problems became rapidly
harder and harder and decided to give up
Getting rid of arrays in Tcl 9 would be insane (I better get caught
up on my core list email) and surely it's been treated as a laugh or
a nonstarter.
I think this guy meant to be provocative and its statement went
uncommented by the audience. It was in the thread you started about
clearing Tcl from unused/obsolete constructs and features.
- Various
* Anyone has any experience/interest with NoSql databases?
We make heavy use of speedtables. This powerful open source
technology (available on github) is possibly the fastest single
machine NOSQL-type database in existence. It can be used locally and
privately, client/server over TCP, or via a combination of TCP and
shared memory. If you're interested in adding some kind of NoSql
support to Rivet I invite you to investigate it as it has been
revolution for us.
thanks for the suggestion, very interesting.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
