jpa-spec
  1. jpa-spec
  2. JPA_SPEC-23

add a prefixing mechanism for @Embedded

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      Currently working with @Embedded is not really user friendly. If you have multiple Embedded fields in an Entity, then you need to excessively use @AttributeOverrides to use them. This is not only a real nightmare to write down, but also an absolute pain when it comes to refactoring or if you just add or remove a column.

      It gets even worse if you have a nested @Embedded structure!

      The solution could be to allow specifying a 'prefix' as JDO knows it for years.

      Let's first look at the Embeddable

      @Embeddable 
      public class Address {
        private String name1;
        private String name2;
        private String street1;
        private String street2;
        private String zip;
        private String tel;
        // ... + getters and setters
      }
      

      (please let's not argue about whether this should better be stored 1:n but just take it as sample for now)

      Then we look at a possible solution with the prefix:

      @Entity
      public class Customer {
       ...
      
        @Embedded(prefix="S_")
        private Address serviceAddress;
      
        @Embedded(prefix="B_")
        private Address billingAddress;
      
        @Embedded(prefix="P_")
        private Address physicalAddress;
      }
      

      You all know what pain it is to do the same in JPA right now ...

        Activity

        Hide
        c.beikov added a comment -

        I think this is related to JPA_SPEC-12 if mutation of the meta- and physical model in case of preCreated callback is allowed.

        Show
        c.beikov added a comment - I think this is related to JPA_SPEC-12 if mutation of the meta- and physical model in case of preCreated callback is allowed.
        Hide
        Paul Benedict added a comment - - edited

        I agree that mixing the logical and physical is not ideal (see comment #1). Besides, if someone wants prefixes, someone else is likely to want suffixes too, or some other complex customization. I propose that the developer should specify a class that can preprocess the column name. The benefit to this approach would be the spec wouldn't dictate/shoehorn the customizations allowed.

        For example, called once per attribute of an emeddable/entity:

        public interface PhysicalCustomizer {
          String customizeColumn(ManagedType<?> mt, Attribute<?,?> attr, String originalColumnName)
        }
        

        Sample usage:

        @Embeddable
        @Customizer(MyPhysicalCustomizer.class)
        
        Show
        Paul Benedict added a comment - - edited I agree that mixing the logical and physical is not ideal (see comment #1). Besides, if someone wants prefixes, someone else is likely to want suffixes too, or some other complex customization. I propose that the developer should specify a class that can preprocess the column name. The benefit to this approach would be the spec wouldn't dictate/shoehorn the customizations allowed. For example, called once per attribute of an emeddable/entity: public interface PhysicalCustomizer { String customizeColumn(ManagedType<?> mt, Attribute<?,?> attr, String originalColumnName) } Sample usage: @Embeddable @Customizer(MyPhysicalCustomizer.class)
        Hide
        Mark Struberg added a comment -

        I see what you mean with the separation of the java side and the db side. Maybe you could see this as 'logical' prefix which by default gets mapped 1:1 to a column prefixing logic like with the column names?

        As for nested embedded fields imo the prefixes should also get nested.

        In our application we use a

        @Embeddable
        public LocalizedText {
          private String en;
          private String de;
          private String fr;
        }
        

        Now imagine that the Address class above has two fields private @Embedded LocalizedText comment with a prefix='C_' and internalInfo with prefix='I_'.

        That would end up with the columns
        S_C_name1, S_C_name2,.. S_I_name1, S_I_name2,... B_C_name1, B_C_name2,...

        Show
        Mark Struberg added a comment - I see what you mean with the separation of the java side and the db side. Maybe you could see this as 'logical' prefix which by default gets mapped 1:1 to a column prefixing logic like with the column names? As for nested embedded fields imo the prefixes should also get nested. In our application we use a @Embeddable public LocalizedText { private String en; private String de; private String fr; } Now imagine that the Address class above has two fields private @Embedded LocalizedText comment with a prefix='C_' and internalInfo with prefix='I_'. That would end up with the columns S_C_name1, S_C_name2,.. S_I_name1, S_I_name2,... B_C_name1, B_C_name2,...
        Hide
        mkeith added a comment -

        Yes, this is a possiblity, although I'm not fond of mixing a logical annotation with a physical column prefix, but the idea is fine, and it wouldn't necessarily need to be part of the embedded annotation.
        Prefixes would presumably not be applied to explicit overrides, so it would be more like a default prefix.
        I suppose the prefix would apply to the nested embeddables as well?

        Show
        mkeith added a comment - Yes, this is a possiblity, although I'm not fond of mixing a logical annotation with a physical column prefix, but the idea is fine, and it wouldn't necessarily need to be part of the embedded annotation. Prefixes would presumably not be applied to explicit overrides, so it would be more like a default prefix. I suppose the prefix would apply to the nested embeddables as well?

          People

          • Assignee:
            ldemichiel
            Reporter:
            Mark Struberg
          • Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: