You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by "Andrus Adamchik (JIRA)" <ca...@incubator.apache.org> on 2007/01/22 12:47:49 UTC

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

Support for embeddable classes
------------------------------

                 Key: CAY-733
                 URL: https://issues.apache.org/cayenne/browse/CAY-733
             Project: Cayenne
          Issue Type: New Feature
          Components: Cayenne Core Library
    Affects Versions: 3.0
            Reporter: Andrus Adamchik
         Assigned To: Andrus Adamchik
             Fix For: 3.0


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.

This is a master task for Embeddable implementation in Cayenne. Specific coding tasks will be tracked via separate linked jira issues.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Posted by Craig L Russell <Cr...@Sun.COM>.
Hi MrG,

On Jan 23, 2007, at 5:37 AM, Michael Gentry wrote:

> 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.

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!


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

Posted by Craig L Russell <Cr...@Sun.COM>.
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.Russell@sun.com
P.S. A good JDO? O, Gasp!


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

Posted by Andrus Adamchik <an...@objectstyle.org>.
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.


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

Posted by Michael Gentry <bl...@gmail.com>.
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 <Cr...@sun.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.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>

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

Posted by Craig L Russell <Cr...@Sun.COM>.
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.Russell@sun.com
P.S. A good JDO? O, Gasp!


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

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jan 22, 2007, at 2:48 PM, 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?

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.

> 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).

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

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

Posted by Aristedes Maniatis <ar...@ish.com.au>.
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?

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