From: Sean O'Dell <sean@...>
Date: 2004-07-01T02:04:47+09:00
Subject: Re: Opinions on library interface design?

On Wednesday 30 June 2004 07:57, Kirk Haines wrote:
>
> I have two thoughts about this.  First would be nice way of telling the
> select() method to return it's data in a different format than the standard
> format.  Maybe via a seperate set of options to the library or via an
> additional parameter passed to the method.
>
> Second would be to have some method attached to the data objects returned
> by Kansas that would have the object return its data in some other object
> format.  Maybe it could be as simple as having the object honor a to_h()
> method or a to_a() method to return a representation of itself as a hash or
> an array?

I think, at every row iteration, you should have a "accept" or "discard" 
method.  Changes probably shouldn't occur automatically without a call to 
"accept", and row iterations without a call to "accept" should automatically 
enact a "discard" action.  That way, only when someone changes data and then 
calls "accept" does the underlying data get called.

Doing it that way means that iterating over thousands of rows to build a web 
page goes fast; no special calls are made just to read data, and changes are 
automatically discarded.  Reads are usually more common than writes, so 
speeding up the read is probably the best idea.

Transforming rows into hashes at each iteration would be a burden to reads, 
which are more common than writes.  I would leave your code alone, and 
present the data the way you are now, but don't write data changes directly 
to the DB.  Cache the changes and write to the DB only when "accept" is 
called.  Discard changes when "discard" is called or when the row is iterated 
again.

	Sean O'Dell