[JPA_SPEC-23] add a prefixing mechanism for @Embedded Created: 10/May/12  Updated: 15/Apr/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Mark Struberg Assignee: ldemichiel
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: RFE


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

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:

public class Customer {

  private Address serviceAddress;

  private Address billingAddress;

  private Address physicalAddress;

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

Comment by mkeith [ 15/May/12 ]

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?

Comment by Mark Struberg [ 20/May/12 ]

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

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

Comment by Paul Benedict [ 11/Apr/14 ]

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:

Comment by c.beikov [ 15/Apr/14 ]

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

Generated at Sun Sep 25 11:26:59 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.