Re: one to one relationship revisited (has_own)

[prev] [thread] [next] [Date index for 2005/01/22]

--- Perrin Harkins <perrin@xxxx.xxx> wrote:

> On Thu, 2005-01-20 at 14:26 -0800, Peter Speltz wrote:
> > i think it would be cool if programs could distinguish if has_a
> relationships
> > were one to one or many to one. AsForm treats them as many to one by making
> a
> > select box of all existing foreign objects. 
> 
> I don't see the difference, from the side of the table that is embedding
> another table's ID.  It can never put the ID of more than one other
> object in that column.
> 

There isn't one there. The difference is that in other parts of the program it
is known that this is a 1:1 and not a M:1 or a 1:0 or 1.  This can be useful to
know for automating things.  

> True one-to-one relationships are not common, since they could always be
> put into the same table.  The current method people usually use for them
> is might_have, where this row's ID is stored in the other table's
> column.
> 

Not common in a single application maybe. But if you're writing many different
applications you come accross them.   Ahh. might_have.  The might part bothered
me before but i understand it better now and it has potential. Please see
scenario at bottom if you have time.

> >  Then AsForm could instead of making a select box of all phones, make input
> > box(s) for column(s) in phone. 
> 
> Sounds more and more like a might_have.  Or maybe just a custom
> presentation that a generic tool like AsForm shouldn't be asked to
> create.
> 

Yes a generic cpan tool maybe shouldn't go that far but an organization's
custom generic tool could if it fits there use case.

> > Furthermore, i thought that create and update may be able to automatically
> > create and update phone:
> > 
> > $prsn = Person->create( {...., phone_id => {...} } );
> 
> That could be added to might_have.  I think that would be useful.
> 
> > Delete however would cascade like has_many.
> 
> It already does with might_have.
> 

Sweet. Thank you. might_have looks very much like the ticket.  But i just don't
feel sure yet.  Form creation and processing (which i do a whole bunch of) is
where i get a nagging feeling that i can get a lot more automation if my
relationships are less ambiguous, like if my class knows: "I difinitely have a
XXX and this XXX only belongs to ME." A possible syntax for this again is
$class->has_own(xxx -> "XXX");

Check this out. I'm real excited about this at the moment. Here is how a
program could handle the common use case of a customer having and might having
different addresses for various things. I think this is cool. Please bear with
me because a simple example won't do here. 

First assume might_have and has_own can take a constraint on another column in
their relative tables -- a "type" column for instance. This means when it looks
up the row in the related table it checks the constraint column for a certain
value so it knows it has the correct row.

Here are customer address table columns:  
Address->columns(All => qw/addr_id cstmr_id addr_type street city state zip/);

Finally, here is how a program would treat might_have and has_own differently.
 
# Declarations
# billing address required
Customer->has_own(billing_address => "Address" => qw/street city state zip/,
                  constraint => {addr_type => 'billing'});
Customer->might_have(service_exists_at => "Address" => (), 
                  constraint => { addr_type => "service" });
Customer->might_have(shipping_address  => "Address" => (), 
                  constraint =>  {addr_type => 'shipping'});

# Much more precise than has_many(addresses => "Address"). 
# We've specified all the types of addresses a person can have and which one 
# is required and consequentially, the default for all the other ones.

So on a New_Customer_Form :  the first declaration tells  a company's module
like  AsForm  to make inputs for steet, city, state, zip. It also knows to make
a hidden input "address_type" with value of "billing".   The controller would
know billing_address fields are required so could validate them.  (If there
were more than one required address (has_own Address), the controller could
duplicate the inputs AsForm returned and prefix the names or something.)

With the second and third declarations, the controller could:
A) make a links like: "If Service Exists At a  Address different from Billing
Address click here" and it could expand the form with more address inputs.
B) Just expand the form to start with by duplicating inputs AsForm returned.
C) whatever else it may want to do -- make a next button to offer optional data
input maybe.

The constraint on might_have makes that possible -- think  has_many hashed on
addr_type 

The general company's AsForm upon seeing the "service_exists_at" and
"shipping_address" accessors/fields could:
A) do nothing since it already made some address inputs and let the controller
copy them if it wants.
B)copy the inputs and prefix the names for the controller if that fits the
company's common use case.


That's it. I hope i've made myself understandable. I have had a lot of coffee
and not much sleep :) Doesn't it seem that many different variations in
Customers could safely have their forms generated and probably processed and
even be created by the same code? Unless i'm missing something, I think a
has_own relationship and constraints to might_have could be powerful and take a
whole lot of guess work out of program logic. 

Thanks and i hope I get more feedback on this. 



=====
pjs


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250