• News
• Introduction
  • Features
  • Why Propel?
  • Technology
  • Requirements
  • License
• Download
• Documentation
  • Propel 1.2
  • Propel 1.3
• Support
  • Mailing Lists
  • IRC
  • Report a Bug
• Development
  • SVN
  • How to Contribute
  • Roadmap
  • Propel Internals
  • Standards & Guidelines
  • Contributors
• Mirrors List
• Powered-by-Propel
• Japanese / 日本語

You are here: WikiStart/Development/Many-to-manyConvenienceMethods

---

Many-to-many Convenience Methods

some simple notes on this from dev list:

Soenke Ruempler wrote:
> Tables:
>
> author
> author_has_book
> book
>
> For now there is a  $author->getAuthorHasBooksJoinBooks() method. IMHO
> there should be a "direct" method like $author->getBooks() that returns
> an array of Book objects.

Yes that's what we have, here are the signatures of we would normally implement in the Author stub:

public function getBooks() // with in object caching which helps a lot

public function addBook(Book $book)

public function removeBook(Book $book)

You need to decide whether these methods should be implemented on both sides of the many<->many, ie should we also have book->getAuthors(). Actually in all of our practical examples there tends to a natural "master-end" of the relationship which has these methods, the other end doesn't seem to need them.

So this asymmetry would have to be specified in schema.xml, as would perhaps the entire decision whether to generate these methods at all for a particular relationship. If done this way, bloat, at least in the generated classes, could be avoided. 



Oliver Schonrock 
Wednesday, March 29, 2006 10:36 AM:

> public function getBooks() // with in object caching which helps a lot
> 
> public function addBook(Book $book)
> 
> public function removeBook(Book $book)

And we'll have to take care of "related by" column - more than one
foreign key. Maybe there is a foreign key direct to book and one over
n:m relation.

So the methods would certainly be known as:

public function getBooksRelatedByAuthorHasBook()
 
public function addBookRelatedByAuthorHasBook(Book $book)

public function removeBookRelatedByAuthorHasBook(Book $book)

Or something similar ...

Oliver Schonrock wrote:
> There used to be a comment in the wiki something like this "future 
> versions of propel will provide much more help for working with 
> many-many relationships".
> 
> I never understood what that "help" was supposed to be. The idea always 
> sounded interesting, because:
*snip*

The idea is that we could flag certain tables in the schema as 
cross-reference (many-to-many) tables and then Propel could 
automatically generate methods that would retrieve rows related through 
that cross-ref table -- e.g. Book->getReaders().

Right now, as you probably know, accessing rows related through a 
cross-reference table is a little cumbersome (well, as cumbersome as it 
is with traditional SQL).

Yeah, I should add that back to the roadmap ...