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
On 1/22/07, Craig L Russell <Craig.Russel..un.com> wrote:
>
> On Jan 22, 2007, at 4:48 AM, Aristedes Maniatis wrote:
>
> >
> > On 22/01/2007, at 10:47 PM, Andrus Adamchik (JIRA) wrote:
> >
> >> JPA specification supports a notion of "embeddable" class.
> >> Embeddable classes can be viewed as multi-column custom types that
> >> do not have their own identity and belong to another persistent
> >> object. Entities that embed them can override DB column mapping.
> >> Currently Cayenne supports single-column custom types via
> >> ExtendedType mechanism. We need to expand that to support multi-
> >> column Embeddables and mapping via the Modeler.
> >
> > 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?
>
> 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
> >
> > 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
> >
> >
>
> 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 - 08:38:25 EST