[JPA_SPEC-23] add a prefixing mechanism for @Embedded Created: 10/May/12 Updated: 15/Apr/14
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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
(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:
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.
|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
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
|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:
|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.