Kirk Haines wrote:

> There are times where one would like to use the query interface to select 
> data, but one does not want the result sets that are returned to be coupled 
> to the database because the data is going to be manipulated in some sort of 
> temporary way.  Maybe we select an array of results and we're going to 
> iterate over them and display them on a web page, but we want to run the 
> array through some sort of filtering or modification first.  The changes are 
> for display only and are not to be applied back to the original data in the 
> database.
> 
> 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?

The first solution seems nicer to me (although the second one doesn't
seem totally exclusive of that). You might add on a parameter or even
use a different method name (select! comes to mind, but it's probably
not appropriate).

For one thing, I can't help thinking that it's more efficient to return
"uncoupled" data except when you need it coupled.

But I am not a db guy, so my opinion is far from definitive.


Hal