Jumping ahead of Craig... The backend logic is like this - an
"embeddable" class has no association with a specific table on its
own, but it can still map to the column names (e.g. "zipCode" ->
"ZIP_CODE"). Entities using an embeddable are free to leave this
mapping unchanged or they can override it to map to different columns.
I think this logic will drive the Modeler UI.
Andrus
On Jan 23, 2007, at 3:37 PM, Michael Gentry wrote:
The reason I ask is because it seems you'd model the Address
separately (and define a street attribute), but then you need some way
to specify how that attribute maps into the table. In the case of
your Employee example, if you have two Address classes, you need some
way to specify the unique column names (HOME_STREET, WORK_STREET) for
each unless it is derived by convention of some kind. Hope that made
sense. I'm just trying to visualize how it might look in the modeler
(UI-issues) and how much extra burden would be involved when creating
the model.
