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:Craig.Russel..un.com
P.S. A good JDO? O, Gasp!
This archive was generated by hypermail 2.0.0 : Tue Jan 23 2007 - 12:04:52 EST