From: Kirk Haines <khaines@...>
Date: 2004-07-01T02:46:50+09:00
Subject: Re: Opinions on library interface design?

On Thu, 1 Jul 2004 02:04:47 +0900, Sean O'Dell wrote
 
> 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.

Hmmm.  What you are describing, basically, is to not autocommit changes.  
This is a configurable setting in Kansas.  When autocommit is off, changes 
to an object only get committed to the database if commit() is called.  If 
rollback() is called, the object is returned to the state it was in 
originally.

That is a viable solution, but I think that I prefer the notion that when 
you use Kansas to select() from the database, you are getting back data that 
is bidirectionally mapped to the database whereas something like browse() 
can be used to perform syntactically identical selects that, rather than 
returning bidirectionally mapped data, return something that is more speed 
and memory efficient for reading (such as plain old DBI::Row objects or 
arrays or whatever), such as what Ara suggested.

This doesn't preclude using the transactional features to avoid accidental 
writes to the database.  That's actually one very good reason to make use of 
the transaction features, IMHO.


Thanks,

Kirk Haines