[Dbix-class] Advise

[Matt S Trout]

Duncan Ferguson wrote:
> On Mon, 2006-07-24 at 19:50 +0100, Matt S Trout wrote:
>> How about just building a set of classes all with the same ->table but 
>> different subsets of the columns? source name != table name, specifically to 
>> avoid tying you down in situations like this.
> 
> Thought about that (as in my original email), but that leaves me without
> an id to identify any pariticular row on, doesnt it?
> 
> I.e., if i have
> 
> id server  state ... ...
> 
> 1 server1 active
> 2 server4 active
> 3 server9 disabled
> 4 server10 disabled
> 
> i guess i can use the id as the primary key if i bung "state" into its
> own package.  My problem is i cannot currently identify what the id
> column will be as there doesnt seem to be any unique key (inc.
> composite) i can use (esp. since too many cols can change which will
> disrupt any composite keysi might decide upon).

Hm. I really can't see any sane way to sort this ... although ...

__PACKAGE__->table(\'(SELECT DISTINCT state FROM fucked_up_table)');
__PACKAGE__->add_columns('state');
__PACKAGE__->set_primary_key('state');

might work.

> I guess I'll have to go beat up the DB designer to see if they can do
> something for me (it doesnt really help that i am new to all the db
> stuff as well - never really done it before)

I think persuade them that it would be nice were the DB actually designed is 
your best option :)

>> (oh, and please start a fresh thread next time :)
> 
> Eh? it is - all in the thread "advise" (badly spelt i know....)

No, you replied to an e-mail in another thread. Any mail client with real 
threading support considers it to be the same thread and merely a change of 
subject line.

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +