> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to