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

Search Discussions

  • Aristedes Maniatis at Jan 22, 2007 at 12:48 pm

    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
  • Andrus Adamchik at Jan 22, 2007 at 1:18 pm

    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
  • Craig L Russell at Jan 22, 2007 at 11:47 pm
    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!
  • Michael Gentry at Jan 23, 2007 at 1:38 pm
    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 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!


  • Andrus Adamchik at Jan 23, 2007 at 2:20 pm
    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.
  • Craig L Russell at Jan 23, 2007 at 5:02 pm
    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!
  • Craig L Russell at Jan 23, 2007 at 5:33 pm
    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!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedJan 22, '07 at 11:48a
activeJan 23, '07 at 5:33p
posts8
users5
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase