Help with collections and relational database

Also note I read about the M2M milestone / minutes from 2008 - from the minutes it appears M2M functionality used to exist out-of-box though was removed due to you guys not fully liking how it behaved.

I also found some generation scripts (gen_cough_collection_methods.php / gen_cough_object_methods.php) which seem to create skeleton Collection and Object classes with a few functions - any clarification on these generation scripts would be great.

Also I forgot to add something in the original post - the Objects mentioned in the documentation / created by the generation scripts - where is the proper place to put these? What are their proper use (layman's terms please)?

Thanks again :)!

Hi Cody,

Thanks for your questions. CoughPHP generates into two different layers:

1. A "concrete" layer. This is the ClassName.class.php file. It is for users to update with any custom business logic or to override the behavior of any generated code. These files start off empty and may be the cause of some confusion.

2. A "generated" layer. This is the ClassName_Generated.class.php file. All detected DB relationships and boilerplate code (some of which can be removed when we make PHP 5.3 version) go here. You should not update this file manually but feel free to use it to see if the methods you expected were generated and also to copy-paste into your concrete class for customization.

The idea here is that you can add custom business logic (e.g. a "cancelOrder" method), change the database schema somewhat (e.g. add/remove a column) and re-generate the classes. CoughPHP will not destroy any of your custom logic and will only update the generated classes with the new column and/or relationships.

Cody,

Good questions!

The generation scripts you found are a shortcut to copy-pasting existing generated code and changing it. Using the scripts you wouldn't have to search/replace the copy-pasted code. But, if FKs are setup and/or the DB uses consistent naming, then you shouldn't have to use those much if at all.

As for where to put the generated objects, I prefer to put them in a "models" directory inside the application (parallel to "views" and "controllers" directories) so that you'd have something like:

 classes/ - one-off classes for the app
 config/ - application configs,
 controllers/
 models/ - CoughPHP generated models
 views/
 modules/ - third-party modules, one folder for each. Some frameworks name this "third-party" or "vendor"

As far as what's inside models, the organization can be customized in many ways:

1. All files floating in that directory
2. Files separated by database.
3. Files separated by type (concrete / safe-to-edit vs generated / NOT safe-to-edit).

For large scale projects that invole many databases I use a combination of 2 and 3, so it'd look something like this:

 models/
  db_name1/
   concrete/
    ClassName.class.php
    ClassName_Collection.class.php
   generated/
    ClassName_Generated.class.php
    ClassName_Collection_Generated.class.php
  db_name2/
   ...

I appreciate the clarification (and am quite surprised at the time in which you replied)!

The only thing I'm still unclear about is if the main generation script is supposed to generate any Collections/Objects by default if it detects FK's?

Yes, the main generation script is supposed to generate collections and objects by default. Each table gets four classes:

1. TableName.class.php - empty class for your customization
2. TableName_Collection.class.php - empty class for your customization
3. TableName_Generated.class.php - all the generated relationships, info about columns, table name, etc.
4. TableName_Collection_Generated.class.php - mostly empty, just refers to the class it's a collection for

The presence of FKs merely allows one to deviate from our naming standards and doesn't change the number of classes generated. FKs (or following naming standard) only changes what relationship methods are generated. For example, in the documentation example of an "author" table with a column named "most_popular_book_id" would generate the following methods if a FK was used to the "book" table:

 public function getMostPopularBook_Object()
 public function setMostPopularBook_Object($book)
 public function loadMostPopularBook_Object()

Without the foreign key, the generator would not create those methods. There are some config options to disable this behavior, but it is enabled by default (see config_examples/more/cough_generator.inc.php):

 'generate_has_one_methods' => 'all', // valid options: all, none, or array of databases to generate join methods for.
 'generate_has_many_methods' => 'all', // valid options: all, none, or array of databases to generate join methods for.

Are you having a specific problem with something not getting generated that you thought should be generated? We'd be happy to help if you could share your schema and config file. Also try running the generation script with "-v" flag: it shows what databases, tables, and relationships it's able to find.