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 ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
