K
Kirk Haines
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.selectProducts) {|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
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.selectProducts) {|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