many-to-many Objects

The current system of handling many-to-many relations is convenient when the relationship itself doesn't hold any additional meaning, however I've come across a situation where I need to validate that the user has permission to (un)make a certain association.

Unfortunately, it has resulted in me needing to define this check twice, once in each associated object's code. Perhaps it would be better to define a class for the association table as well. You would then be able to keep the same many-to-many functions, but they would then call the needed functions on the many-to-many object instead of doing SQL queries themselves.

eg: Employee -> Supervisor would still have Employee::AssociateSupervisorsForEmployeeSupervisor, but it would simply be a wrapper using EmployeeSupervisorAssn::Associate($this, $objSupervisors).

Then, any validation/etc code would be part of the EmployeeSupervisorAssn::Associate function, rather than needing to change both Employee::AssociateSupervisorsForEmployeeSupervisor and Supervisor::AssociateEmployeesForEmployeeSupervisor

True, but we lose all the codegen'd shortcut functionality for that relationship. I beleive changing the codegen system to automatically create the functions in foreign classes, and to create static Assign and Unassign functions in the ORM object would be the ideal approach.

In fact, now that I think about it, that should also allow for other fields in association tables without breaking the codegen.

Hence the feature request to change the codegen. :)

VP... it's definitely a good idea... but implementationn of this becomes quite a nightmare in the codegen templates because of the abstraction that is needed in template programming.  (I've tried this before... and it definitely wasn't pretty. =)

And in fact, with the new querying mechanism that we're hoping to release “any day now” =) in Beta 3... there are some really advanced/neat features with Querying through ASSN tables which would make the entire codebase even more complex if we had to support association table attributes.

However, in reality, using a separate Relationship object doesn't actually lose you anything in terms of functionality.

You still have all the Associate, Unassociate, GetXxxArray functionality... it's just renamed and moved into the Relationship class, itself, instead of codegenned in each of the two joined object classes.  And in fact, it should be relatively straightforward and should only take a few minutes to write wrapper methods to do Associate, Unassociate, GetXxxArray functionality around the Relationship objects generated CRUD methods in the joined object classes.