[Catalyst] Re: Template creates objects via belongs_to (how to lay out relationships)

[Wade.Stuart at fallon.com]

Matt,

      This thread has crossed into a DBIC topic -- I am going to copy the
DBIC list and continue the thread on that list (where it really belongs).
Please join that list at
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class and follow the
discussion.


Kindest regards,
-Wade


Matt Rosin <mattrosin at yahoo.com> wrote on 06/13/2007 10:22:37 PM:

> Hi!
>
> Thank you very much for your help.
>
> My response to your initial comments is "Ahah." I see. Allow me to
> clarify the business logic as you recommend.
>
> 1. A customer may be associated with many transactions, or none at all.
> 2. A transaction can be associated with only a single customer, or
> no customer at all.
> 3. A transaction is either created automatically, in response to
> verification of an incoming IPN (linked to a preexisting customer),
> or the Admin can create a blank transaction to be edited later for
> legacy bookkeeping.
>
> The system is running now at www.thecommunitypage.com which is a
> site showing business listings that allows customers to purchase ads
> and paid listings with automatic fulfillment. When a payment is
> made, a record of the transaction is created, and based on the
> product they bought from the sales catalog, a package associated
> with 0 or more listings are also created. Transactions, packages and
> listings all know the customer who owns them. (White pages listings
> have no package).
>
> Regarding your note about a dummy customer: I use Customer ID 0: no
> record in table, Customer ID 1: Site Owner. So I could make a blank
> record belong to the Site Administrator customer, or I could create
> a dummy customer with id 0, if mysql lets me. In which case in rule
> 2 above the phrase "or no customer at all" could be deleted.
>
> Therefore a Transaction need not always be linked to a customer as
> if by a constraint. I supposed I need to either use NOT_NULL to
> express this fact. Would might_have do the same thing? Its
> documentation seems to be partly finished (the line that begins
> "Assuming"). Could I get the same effect in belongs_to and suppess
> autovivification by adding "cascade_delete => 0" or is this only
> going to work with might_have?
>
> Final question. It looks like maybe I should replace all belongs_to
> to might_have since I don't want autovivification at any time in my
> app. Now I am having a bit of trouble with the docs (probably also
> since I have been infected with CDBI before coming to this) because
> there is also has_one which appears to do just what belongs_to does,
> but backwards. Or is it just like has_a in Class::DBI, in other
> words the inverse of belongs_to? I.e. should one object say
> "has_one" and the other object say "belongs_to"? It seems though
> that I should just use might_have all the time. Also presumably
> has_many will not autovivify even if it has none at all... right?
>
> Thank you and sincere apologies for muddying things,
>
> Matt @ feeling dense today
>