Carl Youngblood wrote:
> You're right of course.  Thanks for pointing that out.  I obviously
> hadn't explored the idea very far.
> 
> On the other hand, I'm wondering why you would want to wait until next
> is called before executing a statement.  If you've called execute, you
> obviously intend to run it.  Why not always execute the statement and
> only do stuff inside next that applies to result sets?  It seems like
> there should be a programatic way to get around this without making it
> necessary for the developer to call two different functions.  Of
> course I'm approaching this more abstractly, not having looked at the
> actual code but simply wondering why something has to be a certain
> way.
> 

A good question. Right now, it is the way it is because that's the way 
the underlying SQLite library works.

   1) You "compile" your SQL statement into a "virtual machine". 
(Corresponds roughly to the Ruby binding's "Statement#execute" method.)

   2) You "step" through your VM one record at a time, with each step 
returning the row that was fetched. (ResultSet#next)

   3) You "finalize" the VM when you are done. (ResultSet#close)

Note that this issue only arises when using result sets directly, from 
statements with side effects (typically DDL statements). Most queries 
can be performed without that level of granularity. In fact, with the 
new "execute_immediate" interface I added, you should never need to 
bother with result sets for DDL statements. In all other cases, you're 
going to call #next to get the next (or first) row anyway.

Still, I'm willing to listen to my users. It would certainly be possible 
for the "execute" method to issue a step call on the underlying virtual 
machine, caching the returned row. Subsequent calls to #next would fetch 
(and cache) the next row, and return the last cached row. It would work 
(and in fact is what you would need to do to implement a DBI interface 
for this binding), but it seems a bit complicated, don't you think? And 
99% of the time, you're never going to be using that level of the 
interface anyway.

Anyway, opinions?

> On Sat, 11 Sep 2004 08:10:27 +0900, Jamis Buck <jgb3 / email.byu.edu> wrote:
> 
>>Carl Youngblood wrote:
>>
>>>What about searching to see if there is no SELECT in the SQL and
>>>executing it immediately if not?  Too kludgy?
>>
>>hmmm, yah, I think so. Consider this statement:
>>
>>   insert into a_table ( a, b, c )
>>      select x, y, z from b_table where...
>>
>>It has a select in it...but returns no rows. You could then say, only
>>those that start with select... but then you have to worry about
>>comments... and there are SQLite commands that work like a select, but
>>don't use the select keyword ("pragma table_info...", etc.).
>>
>>In other words, there no simple answer for determining automatically
>>whether a query should use "execute immediate" or just "execute". :(
>>
>>Anyway, the developer will typically know whether the query they are
>>executing returns rows that they are interested in or not. If not, use
>>execute_immediate. If they want the rows, use execute (and friends).
>>
>>- Jamis
>>
>>
>>
>>
>>>On Sat, 11 Sep 2004 04:46:45 +0900, Jamis Buck <jgb3 / email.byu.edu > wrote:
>>>
>>>
>>>>Vincent Isambart wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>Great job for SQLite/Ruby. It is really great to be able to prepare
>>>>>statements. I have played a little with it today and I have a few remarks:
>>>>>- when you have a statement that does inserts, you must call next on the
>>>>>result set to really execute the statement: stmt.execute { |result|
>>>>>result.next } # the statement is not executed if next is not called
>>>>>It would be great to have it in the FAQ, as it took me some time to
>>>>>understand why my inserts where not working.
>>>>>- a little mistake in the doc SQLite::Statement doc:
>>>>>stmt.bind_variables( 15, "hello" ) should be stmt.bind_params( 15,
>>>>>"hello" )
>>>>>(it was not updated for 2.0.1)
>>>>>
>>>>>Continue you great work ^o^
>>>>>
>>>>>Vincent Isambart
>>>>
>>>>Thanks, Vincent! Great feedback--I'll get your suggestions incorporated
>>>>into the documentation.
>>>>
>>>>Also, would a Statement#execute_immediate method help? It would not take
>>>>a block and would always return +nil+, but then you wouldn't have to do
>>>>an explicit "next" on the result set.
>>>>
>>>>
>>>>
>>>>- Jamis
>>>>
>>>>--
>>>>Jamis Buck
>>>>jgb3 / email.byu.edu 
>>>>http://www.jamisbuck.org/jamis 
>>>>
>>>>"I use octal until I get to 8, and then I switch to decimal."
>>>>
>>>>
>>>
>>>
>>>.
>>
>>
>>--
>>Jamis Buck
>>jgb3 / email.byu.edu 
>>http://www.jamisbuck.org/jamis 
>>
>>"I use octal until I get to 8, and then I switch to decimal."
>>
>>
> 
> 
> .
> 


-- 
Jamis Buck
jgb3 / email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."