Re: Join tables in MySQL

> It seems that MySQL won't let me choose my own PKs via related entites
> - it wants to choose them itself via the eo_pk_table method. Hence I
> could create a new row as long as I don't care what the PKs are, i.e.
> they aren't used as selectable FKs, which defeats the whole purpose of
> a join table.

Your problem is not with MySQL, it is with your model. I use MySQL and  
m-2-m joins all the time.

> So how do I create a row in a join table in MySQL?  Is there some way
> of turnng off the eo_pk_table functionality on join tables only?
>
> Any ideas?

Short answer: investigate "propagate primary key".

Long answer:

When using EOF there is a mindset assumed:

- We think about Objects, not tables.
- We never expose PK's or FK's as class variables, as they are assumed  
to be database artifacts only. If you really need to get the value of a  
PK, use EOUtilities.primaryKeyForObject()
- Since there never exposed, PK's and FK's should never contain data  
with an important value.
- Objects are associated with one another through their relationships.

Given that mindset, lets look at a many to many join:

We have 2 scenarios:

Scenario 1 - The join table *only* has a compound PK made up of the FKs  
of its related Objects. If this is the case then we can forget about  
the join table altogether. It becomes a database artifact that gives us  
the relationships in our joined Objects. It contains no value in  
itself.

For instance: Suppose we have Article objects that are related to  
Category objects. Articles can have many Categories and Categories can  
have many Articles. We would want to ask our Categories for their  
Articles (aCategory.articles()) and Articles for their Categories  
(anArticle.categories()).

Take a look at:

<http://developer.apple.com/documentation/WebObjects/UsingEOModeler/ 
5WorkingWithRelationships/chapter_5_section_7.html>

If you followed those instructions with our Article example you are  
left with a flattened toMany relationship from Article to the Category,  
the intermediate relationships are not exposed. Adding an Article to a  
Category, via one of these relationships, creates the join table  
instance for us. EOF does all the work. Adding an Article to a Category  
becomes:

	EOEditingContext ec // assume exists
	Article anArticle // assume exists
	Category aCategory // assume exists

	anArticle.addObjectToBothSidesOfRelationshipWithKey(aCategory,  
"categories");
	

Scenario 2 - The join table contains additional attributes that have  
value. For instance each Article has a rank associated with each  
Category which is stored in a rank attribute in the join. In this case  
we cannot flatten the relationship between Article and Category because  
we need to expose the intermediate relationships (they now have value).  
We still model them the same way, we just stop before we flatten and  
hide the relationships. In this case you need to perform some extra  
work when creating a relationship between Article and Category.

	EOEditingContext ec // assume exists
	Article anArticle // assume exists
	Category aCategory // assume exists

	ArticleCategoryJoin acjoin = new ArticleCategoryJoin();
	ec.insertObject(acjoin);
	acjoin.addObjectToBothSidesOfRelationshipWithKey(anArticle, "article");
	acjoin.addObjectToBothSidesOfRelationshipWithKey(aCategory,  
"category");
	ec.saveChanges();

I hope that helps,
	
;david

--
David LeBer
Codebase Software Systems
site:   http://www.codebase.ca
blog: http://david.codebase.ca