One-to-Many on one side and Many-to-One on the other:
+------------------+
| Tables_in_tokens |
+------------------+
| token |
| ymcamember |
+------------------+
project --topLevelPackage com.my.tokens
persistence setup --provider HIBERNATE --database MYSQL --databaseName tokens --userName root
// persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY
entity --class ~.domain.Token
entity --class ~.domain.YMCAMember
focus --class ~.domain.Token
field string --fieldName name --notNull --unique
field reference --fieldName ymcaMember --type ~.domain.YMCAMember
focus --class ~.domain.YMCAMember
field string --fieldName name --notNull --unique
field set --type ~.domain.Token --fieldName tokens --mappedBy ymcaMember --cardinality ONE_TO_MANY
controller all --package ~.web
Many-to-Many on both sides:
This represented using a third Junction Table.
Many-to-One from both tables into the new Junction Table which stores the unique-pairs.
+--------------------+
| Tables_in_meetups |
+--------------------+
| community |
| person |
| person_communities |
+--------------------+
This works correctly from a hibernate/jpa standpoint unfortunately the roo UI doesn't acknowledge that one side is the relation owner and so erroneously lets you control it from both sides while persisting from only one. In this case the Person's create page persists properly to the communities table.
project --topLevelPackage com.foo.meetups
persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY
entity --class ~.domain.Community
entity --class ~.domain.Person
focus --class ~.domain.Community
field string name
field set --fieldName members --type ~.domain.Person --mappedBy communities --cardinality MANY_TO_MANY
focus --class ~.domain.Person
field string name
field set --fieldName communities --type ~.domain.Community --cardinality MANY_TO_MANY
controller all --package ~.web
One-to-One on both sides:
This is when each table has a reference to a single row in the other table.
Again the following works well from a JPA/Hibernate point of view but the ui select box needs to be tweaked to allow a nullable field if you need that since it defaults to non nullable for some reason, not a big deal.
+-----------------+
| Tables_in_shoes |
+-----------------+
| left_shoe |
| right_shoe |
+-----------------+
2 rows in set (0.00 sec)
mysql> describe left_shoe;
+---------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------+--------------+------+-----+---------+----------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| name | varchar(255) | NO | UNI | NULL | |
| version | int(11) | YES | | NULL | |
| partner | bigint(20) | YES | MUL | NULL | |
+---------+--------------+------+-----+---------+----------------+
project --topLevelPackage com.my.shoes
persistence setup --provider HIBERNATE --database MYSQL --databaseName shoes --userName root
entity --class ~.domain.LeftShoe
entity --class ~.domain.RightShoe
focus --class ~.domain.LeftShoe
field string --fieldName name --notNull --unique
field reference --fieldName partner --type ~.domain.RightShoe --cardinality ONE_TO_ONE
focus --class ~.domain.RightShoe
field string --fieldName name --notNull --unique
field reference --fieldName partner --type ~.domain.LeftShoe --cardinality ONE_TO_ONE
controller all --package ~.web
Sunday, January 22, 2012
Subscribe to:
Post Comments (Atom)
Great post. Thanks for sharing.
ReplyDeleteSuper Man!
ReplyDelete