[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