Caveats Tips and Tricks, a preread you won't regret!

• If the table you're modeling has a foreign key constraint, the schema must have a belongs_to declarition for it to function properly in an object-relational model. This should reference what the fkey points to ( The table's column it points to will be unique or primary key. )
• No many-to-many can be declaired without first a has_many, as has_many tells DBIx, that you have more than one row pointing back to you in the link table, and then many-to-many will funnel through this relationship
• The link tables in a many-to-many relationship must have two belong_to entries
• The second arguement of a many_to_many decalartion MUST point to a has_many declartion in the same package.

Setting it up

Going for the many-to-many

• accessor name -- This is the method you want this relationship to utilize. If you create a row in a table that has specified a has_many relationship, you can find out what it has_many of by viewing $obj->accessor_name(args)
• table schema of m2m -- This is the DBIx::Class that contains the schema definition of the linking table.
• fkey on m2m -- This is the column name of the foreign key in the linking table thats points to us, ( or stores our primary key. ) Keep in mind this 'fkey' should have in its DBIx::Class a belongs_to entry that specifies the table that makes the has_to declarition.

• One note, the 'accessor name' is also the column name, the column it references too must be in the table the schema describes. THIS IS ALSO what is refrenced

• It should be noted that a M2M is not a relationship, it is a bridge -- mst
• Both arguements to search are hashrefs

• The join clause key - the origin relationship; a relationship defined in the schema you are calling the method 'search' on
• The join clause value - the column on the table that the key (relationship) points to, that will return the destination table