[SearchBuilder-devel] Re: New class DBIx::SearchBuilder::Table

Ruslan U. Zakirov Ruslan.Zakirov at miet.ru
Thu May 26 11:00:09 EDT 2005

	Hello, Pete, Jesse and other.
Have read thread in archive so mailthreading would be broken, sorry.

 > Pete wrote:
 > I'm working on an extension to DBIx::SearchBuilder, namely
 > DBIx::SearchBuilder::Table.  The goal is for it to be a drop-in
 > object to DBIx::SearchBuilder::Record, so that table information
 > can be passed to DBIx::SearchBuilder::Handle::* without changing
 > the structure of the inbound calls. It's an overloaded class such
 > that stringification of the object returns the table name, and
 > in my (somewhat limited) testing, works as expected so far.

Now, DBIx-SB tries handle table info in the Record.pm only with 
_ClassAccessible function. This functions becomes more and more 
complicated and from time to time(rare for me) this info is really 
needed in Handle.pm or SearchBuilder.pm and we use workarounds.
IMHO this is subject to change in 2.0 release, but this is not my 
primary goal because I didn't envestigate this problem much. I'd like to 
refactor&clear current API in 2.0, see ROADMAP thread on this ML.

I don't like overload much because it makes code unclear, also 
stringification still have problems with UTF-8 support.

 > The goal of DBIx::SearchBuilder::Table is to be flexible enough
 > to allow arbitrary data related to the table to be passed around.
 > The idea is to allow things like custom-defined Oracle sequence names
I'd like to see this part, because InterBase/Firebird handle I write 
requires sequences with customizable names.

 > to exist, as well as allow Oracle, Pg, Sybase and ODBC to use
 > something other than 'id' as a primary key.
"Compound PKs" is a problem I would like to solve. It can be partly 
solved in 1.x with backward compatibility. Steps:
* avoid using $record->id method anywhere in the distribution. Now, it's 
used in several places to check if record is loaded or not. We should 
check it like I've done it in LoadFromSQL method when it returns 
'Missing PK field' error(see trunk)
* All Load* methods should return (0, 'Missing PK field')
* Load should take array as argument and map it to fields returned by 
PrimaryKeys method then use LoadByCols.

Main problem is Handle::*::Insert methods, because they return $id as 
result :(, in 1.x it can be done with renaming Handle::Insert into 
Handle::_Insert and make Handle::Insert looks like { return 
(shift)->_Insert(@_) }. This will allow us to override only 
Record::Create sub in our subclasses for "Compound PK" support. Still 
this is a workaround for 1.x and is subject to change in 2.0.

 > I've noticed that there's groundwork in the module for multiple
 > primary keys. My question is twofold: one, does anyone currently
 > use these? And two, has anyone thought about how they'd work
 > central to the module?  e.g. would $sb->Load look like
 > $sb->Load(pk1,pk2) or $sb->Load(pk1=>$pk1,pk2=>$pk2) or...

I vote for $rec->Load(pk1,pk2) syntax for 1.x.

Regards, Ruslan.

More information about the SearchBuilder-devel mailing list