might_have , has_many request

[prev] [thread] [next] [Date index for 2005/02/28]

I'd like it if might_have and has_many relationships took constraints. I've
patched my copies so i can use them the old way or like this:

#############################################################################
package MyCDBI::Customer;

__PACKAGE__->might_have( 'billing_address' => 'MyCDBI::Address' =>
    qw/street city state zip county addr_type/ ,
    { _FK_ => 'owner_id', owner_table => 'customer', addr_type => "Billing"}
);

__PACKAGE__->might_have( 'shipping_address' => 'MyCDBI::Address' =>
    qw// ,
    { _FK_ => 'owner_id', owner_table => 'customer', addr_type => "Shipping"}
);

__PACKAGE__->might_have(
    'cc_address' => 'MyCDBI::Address' =>
    qw// ,
    { _FK_ => 'owner_id', owner_table => 'customer', addr_type => "Credit
Card"}
);


# or has_many :
_PACKAGE__->has_many(
    addresses => 'MyCDBI::Address',
    {_FK_ => 'owner_id', owner_table => 'customer' }
);
   
__PACKAGE__->has_many( 
    checking_accounts => 'MyCDBI::Account',
   {_FK_ => 'cstmr_id', account_type => 'checking'}
);

__PACKAGE__->has_many( 
    savings_accounts => 'MyCDBI::Account',
   {_FK_ => 'cstmr_id', account_type => 'savings'}
);


############################################################

These constraint args just make relationships a little more flexible and make
things go smoother in data creation and user interface.  All constraints are in
meta data so class can do more work for me.  This means on forms  i don't have
to worry about the constraints. So my code is more reusable.

thanks



=====
pjs


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Sports - Sign up for Fantasy Baseball. 
http://baseball.fantasysports.yahoo.com/