I spent a few hours today tracking down a problem in one of @ManyToMany mappings. I thought I'd share my results here in case anyone runs across the same. I'm using Hibernate 3.1.2, HibAnno 3.1beta8 on MySQL. I also checked this with HibAnno 3.1beta9 which I pulled out of SVN today.
I have a Unidirectional ManyToMany relationship between a User object and a Task object. Task is actually an interface implemented by AbstractTask and extended by UserTask.
My original mapping looks like this:
Code:
@ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
@JoinTable(name = "user_tasks",
joinColumns = { @JoinColumn(name = "user_guid") },
inverseJoinColumns = { @JoinColumn(name = "task_guid") } )
public List<Task> getAvailableTasks() {...}
The correct join table would be created and the "user_guid" column would be created and would be of the correct SQL type for my PK. However, the "task_guid" column would be named "elt" and the sql datatype would be tinyblob (I think Hibernate was probably creating it as a varbinary and MySQL was silently turning it into a tinyblob - see
http://dev.mysql.com/doc/refman/5.0/en/ ... anges.html ]
Looking through the documentation for Annotations for @ManyToMany at
http://www.hibernate.org/hib_docs/annot ... ollections I tried changing my mapping to just:
Code:
@ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
public List<Task> getAvailableTasks() {...}
This changed the name of my join table per the default naming conventions, but the column names and types were still the same as before.
Next I tried putting in a targetEntity=AbstractTask.class because this is the superclass of my Task class hierarchy. AbstractTask is marked as a @MappedSuperClass. No luck - same results with both permutations of mappings.
The solution: I changed the targetEntity=BaseTask.class which is explicity mapped in hibernate.cfg.xml and the DDL was generated as I expected.
While this is totally user error on my part, it would be nice to have had Annotations throw out an error message or warning of some kind that it would not figure out the targetClass instead of just creating bad DDL and silently ignoring the inverseJoinColumn attribute.
Hopefully this post will save someone else some time in the future.
Login
FAQ
Search
