You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by "David N. Welton" <da...@dedasys.com> on 2005/11/09 19:53:45 UTC
"DIO" buglet
package require DIO
set dbh [DIO::handle Postgresql dbh -db shopping]
$dbh array "select id, code from codes" res
puts $res(code)
This barfs because 'res' is a magic name. I don't mind picking another
name, but it's a minor annoyance.
Ciao,
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: 'DIO' buglet
Posted by Michael Schlenker <sc...@uni-oldenburg.de>.
Damon Courtney schrieb:
> Do we really need all this? I know David has pushed before to adopt
> nstcl instead of our own little DIO, but I really like the ideas
> behind DIO. I just want to see them evolve now that we've (by we I
> mean Karl and I) had time to use them regularly and see what the
> package really needs.
As i compared db abstraction layers a short while ago, i must say you
should also take a closer look at tcldb from Wojciech Kocjan, at
http://sourceforge.net/projects/dqsoftware/
I hope to find the time to include tcldb into my comparision I sent to
the list last week.
It looks really good from a cursory inspection, although its also based
on itcl, if DIO and tcldb could somehow merge their good features (and
get ported to XOTcl in the medium timeframe)it would be cool.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: 'DIO' buglet
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney wrote:
> Do we really need all this? I know David has pushed before to adopt
> nstcl instead of our own little DIO, but I really like the ideas
> behind DIO. I just want to see them evolve now that we've (by we I
> mean Karl and I) had time to use them regularly and see what the
> package really needs.
You should document and push those ideas some more to the world at
large, because... frankly even I don't have a firm grasp of exactly what
differentiates it from nstcl. I actually have my own database routines
that I've kind of dragged around like a wad of gum stuck to a shoe, but
decided to try DIO out of sheer lazyness for a simple project:-)
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: 'DIO' buglet
Posted by Damon Courtney <da...@tclhome.com>.
> You're right. There's thing thing about DIO where it does an
>
> upvar $arrayName $arrayName $arrayName array
>
> ...and I'm not totally sure why... it's some sort of Damon magic.
Uh... probably something really stupid on my part. 0-] Not sure why
the double $arrayName would be there when the array variable will work
just fine. Need to get in there and look at the code.
> I've been working on DIO. It's fairly high overhead, creating an
> object for every result, and it pulls several result variables across
> to the result object whether they're requested or not... stuff like
> that. I've been toying with the idea of trying to reuse result
> objects due to the overhead of Itcl object creation. Also
> occasionally studying Xotcl since that's the forthcoming "official"
> object system.
I'd like to see a switch to XOTcl. Not sure what kind of work it
would be. There doesn't seem to be a lot of push for Itcl anymore
these days. Even David hates it. 0-]
I'm really beginning to rethink the whole "every result is an object"
idea. I like it in some respects, but it really does create some
overhead that most people just don't care about. Hell, these days, I
usually just want to iterate over all of the results and destroy the
object anyway. The object itself is basically useless to me other
than to encapsulate some result data. *shrug*
> One thing that makes it difficult is I'm a PostgreSQL guy and not a
> MySQL/SQLite guy. A recent case in point, I want the "DIO update"
> method to return the number of rows affected, but it's a different
> result method, pgresult -cmdTuples rather than pgresult -numTuples,
> and I don't know how the others handle that.
I'm definitely more a Postgres guy than anything else, but I also do a
lot of Mysql and Oracle work. Not much on Sqlite at all (though I
really dig it), but I think if we're gonna' rethink this thing, we
need to take Sqlite into account. It's method of handling results is
more like where we probably need to go. You can't fetch individual
rows at a time, you just process the whole result set in a loop.
This is what I go more towards anyway, and I know Karl does too. I
rarely find the occassion to do anything BUT process the whole result
set. It would certainly be a lot faster. Sqlite and Oracle both
process their results this way. We have to do a lot of fiddling in
DIO to make it work otherwise (usually cacheing entire result sets
into an array).
Do we really need all this? I know David has pushed before to adopt
nstcl instead of our own little DIO, but I really like the ideas
behind DIO. I just want to see them evolve now that we've (by we I
mean Karl and I) had time to use them regularly and see what the
package really needs.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: "DIO" buglet
Posted by Karl Lehenbauer <ka...@sc.com>.
You're right. There's thing thing about DIO where it does an
upvar $arrayName $arrayName $arrayName array
...and I'm not totally sure why... it's some sort of Damon magic.
But yeah, that's the problem, any array name that's also a variable
inside the method or a public variable of the class and it's gonna fail.
I've been working on DIO. It's fairly high overhead, creating an
object for every result, and it pulls several result variables across
to the result object whether they're requested or not... stuff like
that. I've been toying with the idea of trying to reuse result
objects due to the overhead of Itcl object creation. Also
occasionally studying Xotcl since that's the forthcoming "official"
object system.
One thing that makes it difficult is I'm a PostgreSQL guy and not a
MySQL/SQLite guy. A recent case in point, I want the "DIO update"
method to return the number of rows affected, but it's a different
result method, pgresult -cmdTuples rather than pgresult -numTuples,
and I don't know how the others handle that.
On Nov 9, 2005, at 12:53 PM, David N. Welton wrote:
> package require DIO
>
> set dbh [DIO::handle Postgresql dbh -db shopping]
>
> $dbh array "select id, code from codes" res
>
> puts $res(code)
>
> This barfs because 'res' is a magic name. I don't mind picking
> another
> name, but it's a minor annoyance.
>
> Ciao,
> --
> David N. Welton
> - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
> - http://www.dedasys.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org