On Thu, 2005-12-29 at 11:51 -0600, Peter Speltz wrote:
> As it is now, A custom method would be easy to write that uses a search.
>
> # Get the related row from Results table
> sub MyDB::Problem::results {
> my ($obj) = shift;
> return MyDB::Results->search( version => $obj->version,
> resolution => $obj->resolution, precision => $obj->precision);
> }
No need for a search when you're looking up a primary key. Just use
retrieve(). It works fine for multi-column primary keys. This is the
approach I use when I need has_a for multi-column keys. Very easy.
> Not sure what you mean here. Working on new apps so far I have
> always made it a point to use single PKs. That way they are there when
> I need them and I can still treat other columns as part of a Key when
> I need to. However I probably have just not been doing this long
> enough to discover the benefit of true Mult column primary keys.
In my opinion, this kind of artificial key is an unnecessary kludge.
The multi-column key is already a unique identifier, and the database
enforces it.
- Perrin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Maypole-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-users
