[Cayenne-dev] [JIRA] Created: (CAY-733) Support for embeddable classes

When would you use such a thing? I am trying to think of how this is
useful, but perhaps I'm missing the point of the concept. Would this
be used to create a type of inheritance between classes, such as
company and person having a common billing address class but relating
back to completely separate address fields in each of the company and
person tables in the db?

Also, is it a goal to make 3.0 fully JPA compliant or is that too
ambitious in the timeframe (I'm guessing a reasonable target for 3.0
would be some time in 6-9 months).

Ari Maniatis


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

Indeed IMO this is somewhat of an optional edge case in ORM (although
the JPA spec does require it). It adds extra flexibility to the
object design, allowing to map a composition of objects to a single
table. I think your inheritance example is a good one - you can have
the same Java class with specific OO behavior (e.g. Address) shared
across different entities and mapped to different columns.
Yes - the goal is to make 3.0 fully compliant. Although I'd postpone
the final decision till we finally start in-container integration
testing and running against the Sun TCK. In any event the plan is to
start posting 3.0 milestone releases ASAP.

Andrus

The simple case is the Address class that is contained in multiple
classes, e.g.

class Employee {
Address homeAddress;
Address workAddress;
...
}

class Business {
Address primaryAddress;
...
}

The EMPLOYEE table contains columns HOME_STREET, HOME_CITY,
HOME_STATE, HOME_ZIP, HOME_COUNTRY, WORK_STREET, WORK_CITY,
WORK_STATE, WORK_ZIP, WORK_COUNTRY. The BUSINESS table contains
columns PRIMARY_STREET, PRIMARY_CITY, PRIMARY_STATE, PRIMARY_ZIP,
PRIMARY_COUNTRY.

There is no separate Address table and no Address instance that
exists outside the "owning" Employee or Business instance.

Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Hi Craig,

I'm pretty ignorant on the JPA stuff so far, but from an accessor
point of view, I'm assuming it would look something like this:

anEmployee.getHomeAddress().getStreet();

I wouldn't imagine there is a roll-up of the attributes into the main
class at all. Also, are the database column names (HOME_STREET)
inferred or is that something that would still be specified by model
mapping? 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.

Thanks,

/dev/mrg

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

Hi Andrus,

Thanks for jumping ahead, since the modeler is not my area of expertise.

more below...
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
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Hi MrG,
Correct. The only visibility in the enclosing class are the
properties HomeAddress and WorkAddress. All of the address columns in
the table are mapped into properties in the HomeAddress and WorkAddress.

Craig


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!