Hi Andrus, Thanks for jumping ahead, since the modeler is not my area of expertise.
more below... On Jan 23, 2007, at 6:19 AM, Andrus Adamchik wrote:
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
Typically, you do model the Address itself as a persistence-capable class (this allows you to do some clever change-detection processing on Address instances) but you map the Address differently in each use case. That is, model columns in the table for each usage of Address to properties of the embedded Address class.
So yes, there is more work, because each occurrence of Address in the model has to be mapped separately.
Craig
(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.
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
