Help with collections and relational database

Asked by Cody

Unfortunately I've scoured for hours but the lack of documentation has lead me here - it has more to do with my lack of understanding of the general setup of CoughPHP I'm sure, though I figured I'd ask and other people can benefit from this.

Now the biggest issue I'm having is having is with any sort of relations in the database. It _appears_ that I have to write my own collections in the skeleton classes that the cough generation script creates, though I'm not positive. The documentation implies that there was methods already available for relational purposes:

// Get's all of the authors aliases accordingly (from the handbook)
$aliases = $author->getAlias_Collection();
.. truncated

Unfortunately I can't find any good documentation or examples on what this is actually doing / how much of it I should write myself.

I suppose I have two questions, the scope of the latter is a bit large / newbie so feel free to point me in the right direction rather than fully holding my hand:

1) Are the Table_Collections classes supposed to be auto generated with some methods in them? Or are collections meant solely for me to create / use with relational databases. Is there any way to utilize many-to-one / many-to-many (I saw the milestone just throwing it in for the sake of it) out-of-box?

2) If no to the first question, is there any projects and or examples of how to properly (I'm OCD) handle relations (both one-to-one and many-to-many)?

Any sort of direction would be appreciated, I'm really falling in love with both of your projects (LightVC / CoughPHP) though unfortunately my lack of understanding is making it difficult to use it.

Thanks for reading!

Question information

English Edit question
CoughPHP Edit question
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Cody (billzy) said :

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 :)!

Revision history for this message
Anthony Bush (awbush) said :

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.

Revision history for this message
Anthony Bush (awbush) said :


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,
 models/ - CoughPHP generated models
 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:


Revision history for this message
Cody (billzy) said :

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?

Revision history for this message
Anthony Bush (awbush) said :

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/

 '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.

Can you help with this problem?

Provide an answer of your own, or ask Cody for more information if necessary.

To post a message you must log in.