[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Opinions on library interface design?
From:       "Sean O'Dell" <sean () celsoft ! com>
Date:       2004-06-30 18:26:23
Message-ID: 200406301126.20003.sean () celsoft ! com
[Download RAW message or body]

On Wednesday 30 June 2004 10:46, Kirk Haines wrote:
> 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.

If you prefer a browse method which is analogous to select, except that it's 
read-only, then I would make browse simply turn off autocommit and then call 
select.  That way you are always giving row data to the developers using the 
same objects; they don't have to re-write any code to suddenly decide that 
they need to make small changes to a row as they iterate through a table.  
Your pattern here could be "select creates a return set and changes to fields 
are written, browse creates the same return set but changes to fields are 
ignored."  You could also allow changes to the data set returned by browse to 
be written back to the database with an explicit call.

If you want hash-like functionality for your rows for both select and browse, 
do something like what Ara did with arrayfields.  Write a special method that 
accesses fields in a row by name, so you can say: 
dataset.fields_by_name['id'] or dataset.fields[0] and if id is the first 
field in the row, both return the same value.  You could also allow setting 
the field to a new value this way.

	Sean O'Dell

[prev in list] [next in list] [prev in thread] [next in thread]