From: Kirk Haines <khaines@...>
Date: 2004-06-30T23:57:32+09:00
Subject: Opinions on library interface design?

I have a question about an interface design issue for Kansas that I wanted 
to get some general input on.

Kansas, if you are unaware, is an object-relational mapping library.  Result 
sets from queries are returned as hash-like objects.  However, be object 
knows where it came from, and updating the object causes the underlying 
database data to be updated transparently.  This lets one manipulate the 
data without worrying about writing SQL.

i.e.

-----
discontinued_products = ksdbh.select(:Products) {|p|
  p.idx.between(104,114)}

discontinued_products.each do |dp|
  dp.name = "#{dp.name} (DISCONTINUED)"
  dp.status = 'unavailable'
end
-----

This small example would select all products with an idx between 104 and 114 
from the database.  Then by iterating over the array and changing attributes 
on the objects, we change the underlying database.  Great.  Okay, now for 
the question.

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 approach includes more magic.  However, if I am doing a select on 
10000 rows, and I want to retrieve them simply as hashes, it'd be nice to be 
able to easily tell Kansas that for this query, return the result set as 
hashes without having to return the result set as a db coupled object, then 
iterate through all of them asking for hash representation of each.

So....what is a nice, elegant way to tell select() that I want the result 
set back as hashes, or arrays (or arrayfields), or structs, or whatever, 
instead of the default db coupled objects?

Thanks in advance for your ideas,

Kirk Haines