CHAPTER 8 Legacy databases and custom SQL mapping (Shared web hosting)

CHAPTER 8 Legacy databases and custom SQL mapping to create a literal join condition from the association table to the entity table(s). Unfortunately, at the time of writing, Hibernate Annotations doesn t support arbitrary join conditions expressed with formulas. The grouping of properties under a reference name also wasn t possible. We expect that these features will closely resemble the XML mapping, once they re available. Another issue you may encounter in a legacy schema is that it doesn t integrate nicely with your class granularity. Our usual recommendation to have more classes than tables may not work, and you may have to do the opposite and join arbitrary tables into one class. 8.1.3 Joining arbitrary tables We ve already shown the mapping element in an inheritance mapping in chapter 5; see section 5.1.5, Mixing inheritance strategies. It helped to break out properties of a particular subclass into a separate table, out of the primary inheritance hierarchy table. This generic functionality has more uses however, we have to warn you that can also be a bad idea. Any properly designed system should have more classes than tables. Splitting a single class into separate tables is something you should do only when you need to merge several tables in a legacy schema into a single class. Moving properties into a secondary table Suppose that in CaveatEmptor, you aren t keeping a user s address information with the user s main information in the USERS table, mapped as a component, but in a separate table. This is shown in figure 8.4. Note that each BILLING_ADDRESS has a foreign key USER_ID, which is in turn the primary key of the BILLING_ ADDRESS table. To map this in XML, you need to group the properties of the Address in a element: Figure 8.4 Breaking out the billing address data into a secondary table
We recommend high quality webhost to host and run your jsp application: christian web host services.