[JPA_SPEC-133] Make TABLE-generated IDs available on PrePersist Created: 09/Aug/16  Updated: 22/Aug/16

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

Type: Improvement Priority: Minor
Reporter: jinahya Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: generator, id, lifecycle

 Description   

JSR-338/3.5.3 states that

> Generated primary key values are available in the PostPersist method.

It'll be much helpful if those ids whose strategy is GenerationType.TABLE are available on PrePersist.

exempli gratia

public class MyEntity {

    @PrePersist
    private void onPrePersist() {
        // generate a unique and unchangable value from *available* id.
        derived = String.format("%1$016x", id);
    }

    @GeneratedValue(..., strategy = GenerationType.TABLE)
    @Id
    private Long id;

    @Basic(optional = false)
    @Colum(..., nullable = false, updatable = false)
    @NotNull
    private String derived;
}

Note that the derived column is not null and not updatable.



 Comments   
Comment by neilstockton [ 22/Aug/16 ]

FWIW DataNucleus JPA already does set ids from all non-IDENTITY value generators (i.e TABLE, SEQUENCE, custom) prior to PrePersist, so hence the values are available in that method.





[JPA_SPEC-132] Change TableGenerator/initialValue's type to long Created: 05/Aug/16  Updated: 05/Aug/16

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

Type: Improvement Priority: Minor
Reporter: jinahya Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: TableGenerator
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

On some systems, initialValue need to be set with a large starting number bigger than Integer.MAX_VALUE.
Requesting considerations.






[JPA_SPEC-116] remove raw types from JPA API Created: 14/Sep/15  Updated: 14/Sep/15

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

Type: Task Priority: Minor
Reporter: Lukas Jungmann Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

goal is for the API to compile cleanly but the key requirement is for API to remain backward compatible






[JPA_SPEC-109] Allow AttributeConverters to be CDI injectable Created: 11/May/15  Updated: 01/Nov/15

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

Type: Improvement Priority: Minor
Reporter: Xavier Dury Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Since JPA 2.1, EntityListeners can be injected through CDI.

AttributeConverters could also be injectable in order to centralize conversion logic that can be shared between multiple components (like JSF Converters that will also be made injectable in 2.3).



 Comments   
Comment by Lukas Jungmann [ 13/Oct/15 ]

the request is to allow injection in the converter, right?

Comment by Xavier Dury [ 13/Oct/15 ]

indeed.

Comment by Lukas Jungmann [ 14/Oct/15 ]

thanks for confirming this. It wasn't clear from the initial description. Planned for the next release (the one currently in progress)

Comment by Lukas Jungmann [ 01/Nov/15 ]

implemented in RI, to try: https://www.eclipse.org/eclipselink/downloads/nightly.php if maven is prefered then see https://wiki.eclipse.org/EclipseLink/Maven for the repo setup





[JPA_SPEC-108] Path.get(PluralAttribute<X, C, E>) lower bound missing on X Created: 28/Apr/15  Updated: 28/Apr/15

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

Type: Bug Priority: Minor
Reporter: mmariotti Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Path interface declares:

<E, C extends java.util.Collection<E>> Expression<C> get(PluralAttribute<X, C, E> collection);

it should be instead

<E, C extends java.util.Collection<E>> Expression<C> get(PluralAttribute<? super X, C, E> collection);

with lower bound on X.
The same apply on Path.get(MapAttribute<X, K, V>).






[JPA_SPEC-100] Allow an empty collection_valued_input_parameter in an "IN" expression Created: 21/Feb/15  Updated: 21/Feb/15

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

Type: Improvement Priority: Minor
Reporter: Anthony Vanelverdinghe Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In section 4.6.9, In Expressions, it should be specified that an empty collection_valued_input_parameter must not result in an exception. More specifically:

the expression
o.country IN (:countries)
must be treated as false

and the expression
o.country NOT IN (:countries)
must be treated as true

This should be trivial for JPA implementations to implement, since they can simply replace the expression with an expression like "1 = 0" or "1 = 1".

Currently, JPA implementations throw an exception in this case, which makes it cumbersome to use collection valued input parameters.






[JPA_SPEC-92] Sharing a single version field between multiple entities Created: 01/Oct/14  Updated: 01/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Xavier Dury Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have been using Hibernate then JPA for almost 10 years and there is one feature that I miss and would like to be discussed by the EG.

Currently, in JPA, with a typical (bi-directional & mapped) Parent-Child relationship, the parent gets versioned when a child is added or removed from the parent collection.

I would like to know if it is possible to version the parent when a child is updated without artificially updating a dummy property on the parent (let's say lastModificationDate).

I'd like to do that to preserve an objects' graph coherence (invariants).

example:

I have the following entities:

[Order] 1 --- * [OrderLine (quantity)] * --- 1 [Product (price)] 

and have a rule (at the order level that can be implemented with javax.validation) that the total amount for an order (= sum quantity * price for each line) must not be greater than $5000.

If two users concurrently modify the same order by changing the quantity of 2 different lines, the last one committing won't see the changes made by the first one (even if each OrderLine has a @Version property) and won't be able to enforce the invariants on the parent order.

However, if the order itself is versioned at each commit (even if none of its direct property has changed but one of its children has been modified), the last one committing will get an OptimisticLockException (and the order won't be corrupted).

Therefore, I would like to be able to specify something like this:

@Entity
class Order {

    @Id
    Long id;
	
    @Version
    Integer version;
	
    @OneToMany(cascade = ..., mappedBy = "order")
    Set<OrderLine> lines;
}

@Entity
class OrderLine {

    @Id
    Long id;
	
    @ManyToOne
    @Version // if this orderLine changes, bump the version of the whole order
    Order order;
}

That way, I could have a single version field for a graph of objects. Speaking with Domain-Driven Design in mind, this would result in having a version field only on the aggregate root.

What do you think?






[JPA_SPEC-84] Add support for EL expressions in JPA-QL and native queries. Created: 18/Jul/14  Updated: 19/Jul/14

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

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


 Description   

This proposal suggests adding support using EL expressions in JPA query strings. With this one could define query string templates and dynamic parameter bindings based on EL (Expression Language).

  • Immediate evaluation (via $ {...}) could be used to statically alter the query string in cases where the user
    wants to statically generate a fixed part of a query. This could be used to add query fragments or adjust the name
    of tables or columns / fields.
    - Deferred evaluation (via #{...}

    ) could be used to dynamically compute a parameter value in cases where the user
    wants to avoid having to compute and set the parameter values explicitly.

Example 1

The JPA-QL query:

select o from BusinessObject o where o.owner.emailAddress like ?#{hasRole('ROLE_ADMIN') ? '%' : principal.emailAddress}

would translate to:

select o from BusinessObject o where o.owner.emailAddress like ?1

With ?1 bound to the result of the dynamically evaluated EL expression hasRole('ROLE_ADMIN') ? '%' : principal.emailAddress. The parameter ?1 would be dynamically registered.

Example 2

The JPA-QL query:

select o from BusinessObject o where o.owner.emailAddress = ?1 ${ currentTenant != null ? ' and o.tenant = ?#{' + currentTenant.id + '}' : ''}

would translate to either:

select o from BusinessObject o where o.owner.emailAddress = ?1

or:

select o from BusinessObject o where o.owner.emailAddress = ?1 and o.tenant = ?2

where ?2 is bound to the result of the dynamically evaluated expression "currentTenant.id".

It would be helpful to have some kind of SPI at the EntityManagerFactory that allows libraries or users to customize the EL expression context somehow, e.g. by allowing to expose functions, properties, variables and the like.

javax.el.Expression as JPA Query parameter values

As an extension one could also allow to bind parameter values of type javax.el.Expression to every exposed parameter of a JPA query. The value to be bound could then derived at query time by evaluating the given expression. We implemented that feature in the latest version of the Spring Data JPA Repository abstraction.



 Comments   
Comment by thomasd [ 18/Jul/14 ]

Sorry for the bad formatting...
I wanted to fix it, but I cannot edit the issue anymore

It should look like the following gist:
https://gist.github.com/thomasdarimont/96ca7a913c8b0ffcf970

Cheers,
Thomas





[JPA_SPEC-82] Add an EntityManager#getReference() method that takes an ID and a version Created: 01/Jul/14  Updated: 01/Jul/14

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

Type: Improvement Priority: Minor
Reporter: ljnelson Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Please consider adding an EntityManager#getReference(Class, Object, Object) method to the JPA specification.

The method's purpose should be to return an entity provided that its identifier and version are equal to the supplied parameters.

It should be possible to pass null as the third parameter (version).

The javadoc could read something like the following:

/* 
 * Get an instance, whose state may be lazily fetched, provided that the
 * supplied class, identifier and version parameters collectively identify the
 * persistent representation of the entity in question.
 *
 * <p>If the requested instance does not exist in the database, an 
 * {@link EntityNotFoundException} is thrown when the instance state
 * is first accessed. (The persistence provider runtime is permitted to throw
 * the {@link EntityNotFoundException} when {@code getReference} is
 * called.)</p>
 * 
 * <p>The application should not expect that the instance state will be  
 * available upon detachment, unless it was accessed by the application while 
 * the {@link EntityManager} was open.</p>
 *
 * @param entityClass the {@link Class} of the entity being sought; must not
 * be {@code null}
 * 
 * @param primaryKey the identifier of the entity being sought; must not be
 * {@code null}
 *
 * @param version the version of the entity being sought; may be {@code
 * null} in which case this method will behave in exactly the same manner as
 * the {@link #getReference(Class, Object)} method
 *
 * @return the found (non-{@code null}) entity reference
 *
 * @exception IllegalArgumentException if {@code entityClass} does not 
 * denote an entity type or {@code primaryKey} is not a valid type for that
 * entity's primary key or is {@code null}
 *
 * @exception EntityNotFoundException if the entity state cannot be accessed
 */

The background for this issue can be accessed in the following email thread: https://java.net/projects/jpa-spec/lists/users/archive/2014-06/message/0






[JPA_SPEC-81] @Version Support for Temporal Types Created: 22/May/14  Updated: 22/May/14

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

Type: Improvement Priority: Minor
Reporter: shelleyb Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JPA 2.1 specification currently indicates that Timestamp is the only supported temporal type for @Version properties:

The following types are supported for version properties: int, Integer, short, Short, long, Long, Timestamp.

I'd propose that additional temporal types are supported as well:

java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp



 Comments   
Comment by shelleyb [ 22/May/14 ]

For reference, Hibernate already seems to support this, and as such, we had initially overlooked this jpa limitation and are already using @Version java.util.Calendar in our entities, and I have observed this usage elsewhere as well:

https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-declaration-timestamp





[JPA_SPEC-77] EntityManager(Factory) should implement AutoCloseable Created: 13/Apr/14  Updated: 28/May/15

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

Type: Improvement Priority: Minor
Reporter: braghest Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: autocloseable, java_7

 Description   

EntityManager and EntityManagerFactory have #close() methods but do not implement AutoCloseable. Implementing AutoCloseable would allow them to be used in Java 7 try-with-resource statement.



 Comments   
Comment by flutter [ 21/May/15 ]

This would mean to drop Java 6 support, right?

Comment by braghest [ 22/May/15 ]

That would mean dropping Java 7 support but then again Java EE 7 requires Java SE 7.

Comment by neilstockton [ 28/May/15 ]

It would mean dropping Java 1.6, yes. But then Java 1.6 and Java 1.7 are BOTH end of life now.
By the time the next version of JPA happens (who knows when that is), Java 1.8+ should be the baseline, hence no reason why this issue can't be included.
+1





[JPA_SPEC-68] update and/or validate javax.persistence.schema-generation.database.action Created: 12/Nov/13  Updated: 12/Nov/13

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

Type: Improvement Priority: Minor
Reporter: steveschols Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: schema-generation, update, validate

 Description   

I think that an "update" and a "validate" schema-generation.database.action might come in handy, especially for production environments where Java EE 7 will be running in the comming future.

Of course you don't want your database to be accidentally being removed if you still have the "create-drop" enabled, and a new action won't solve that.
But without the "update" action you still have to resort to solutions like Google Flyway or DbMaintain to update an existing database schema.

Are there plans to incorporate a new action like "update" or "validate", the way Hibernate supports it?
Or are they left out by design?






[JPA_SPEC-65] Need another property to make lazy loading of attributes easy with entity graphs Created: 31/Aug/13  Updated: 31/Aug/13

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

Type: Bug Priority: Minor
Reporter: mkeith Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There are currently two properties to use with entity graphs:

javax.persistence.fetchgraph -

This property accepts an entity graph to act as a complete override of all the attributes for the type. Attributes are dictated to be eager if included or lazy if excluded from the graph, regardless of how they are mapped.

javax.persistence.loadgraph -

This property offers a selective eager approach. One can simply add the attributes that one wants to be eagerly loaded and the rest are left as they are statically mapped.

The missing property would be something to allow more convenient selective lazy overriding without having to declare the entire attribute set for the type (as required by fetchgraph). So something like:

javax.persistence.lazygraph -

This property would offer a selective lazy approach. One would be able to add the attributes that one wants to be lazily loaded to the graph, with the rest being left as they are statically mapped.






[JPA_SPEC-64] EntityGraph API has unspecified List/Map getters Created: 27/Aug/13  Updated: 27/Aug/13

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

Type: Bug Priority: Minor
Reporter: mkeith Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The List/Map getter methods (e.g. getAttributeNodes()) on EntityGraph, AttributeNode, and Subgraph do not specify whether the List/Map returned is a mutable one or a copy. They should be specified as returning the exact collections so the collections can be mutated. If it is a copy then the ability to mutate an existing named entity graph using createEntityGraph(String) is quite limited. There would be no way to remove an attribute node or a subgraph, or for that matter even add a subgraph for an existing attribute node.

The alternative to returning the actual collections is to add methods to the API to enable the additional mutating operations.






[JPA_SPEC-59] Clarify namespaces of type aliases and named parameters Created: 11/Jun/13  Updated: 11/Jun/13

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

Type: Improvement Priority: Minor
Reporter: Matthew Adams Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JPA 2.1


Tags: jpa, jpql, parameter

 Description   

JPA 2.1 Section 3.10.12, "Named Parameters", does not explicitly require that the namespaces of type aliases and named parameters be distinct. Some implementations fail & some succeed on JPQL of the following form:
SELECT x FROM Thing x WHERE x.foobar = :x

The specification should be explicit as to whether type aliases and named parameters share the same namespace.






[JPA_SPEC-53] Schema generation with existing EMF Created: 26/Mar/13  Updated: 05/Apr/13

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

Type: Improvement Priority: Minor
Reporter: Christian Bauer Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I've been running into a conceptual issue with schema generation in JPA 2.1 and how unit tests are typically organized.

Let's say you want a clean database for every unit test method. I prefer to create the schema in the database before every test method, and then drop it after the test method completes.

I have a single EntityManagerFactory for the whole test class, it can be shared by every test method. This is possible with the Hibernate API, the schema generator uses an existing EMF configuration to produce the create/drop scripts.

With the static Persistence.generateSchema() in 2.1 this approach doesn't work. Calling generateSchema() internally builds a new EMF every time.

One of the problems is that you get new automatically generated foreign key names every time you call generateSchema(). The "drop" action therefore always fails, unless you define all foreign key names in your metadata. There could be other automatically generated artifact names, so the "drop" action in general, if called from a static context, is not useful during development.

The current solution then is to specify "drop-and-create" and to build and close an EMF for every unit test method. This means starting and stopping the persistence provider for every test method, slowing down test runs significantly.

A better solution would be an additional Persistence.generateSchema(EMF, properties) method that accepts an existing EMF and some "override" properties.



 Comments   
Comment by Christian Bauer [ 04/Apr/13 ]

Additionally, consider adding the database action "create-drop". This would issue CREATE statements when the EMF is build, and DROP statements when the EMF is closed. Granted, this is a useless setting with static Persistence.generateSchema() but it would, in addition to the above proposed changes, give you full flexibility for schema generation. Use case is for example a @BeforeMethod in a test harness that builds an EMF and an @AfterMethod that closes the EMF.





[JPA_SPEC-52] createNativeQuery(String, Class) Created: 20/Mar/13  Updated: 05/May/14

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

Type: Improvement Priority: Minor
Reporter: agoerler Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

I've got a minor suggestion:

EntityManager.createNativeQuery(String, Class)

could return a TypedQuery as the result class is specified:

TypedQuery<T> createNativeQuery(java.lang.String sqlString,
java.lang.Class<T> resultClass)

-Adrian



 Comments   
Comment by edvin [ 05/May/14 ]

Is there a more complex underlying reason for this not being fixed? At first glance it seems trivial.





[JPA_SPEC-42] Allow null @Embedded Objects Created: 17/Jan/13  Updated: 05/Apr/13

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

Type: Improvement Priority: Minor
Reporter: reza_rahman Assignee: ldemichiel
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

At the moment, it is not possible to have null @Embedded objects in JPA (while Hibernate, etc allow it). This is quite a common scenario in most domain models that JPA should take into account. The following is an example:

<pre>
public class Employee {
...
@Embedded(optional=true) // This should be possible since the employee entity can be null in some
// stages of it's life-cycle
private Address address;
...
}
</pre>






[JPA_SPEC-30] Case sensitivity in JPQL queries Created: 24/May/12  Updated: 23/Nov/15

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

Type: New Feature Priority: Minor
Reporter: arjan tijms Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: RFE

 Description   

In JPA 2.0, JPQL is case insensitive. This means that contrary to Java code, an identifier can not be same name as an entity with the first letter in lower case.

For instance in the following query an underscore has to be added to make the name legal:

SELECT
    _user
FROM
    User _user

Other typical workarounds for this are abbreviating the identifier to e.g. "u", "usr" etc. Such names are rarely a best practice and actually against common advice for good naming given by books like Clean Code, etc.

I would like to request support for case sensitivity in some way, or alternatively to lift the requirement that identifiers may not have the same name as Entity classes. This last approach is taken by some persistence providers, e.g. Hibernate, which silently accepts identifiers having the same name as Entities.

One possible solution would be to use a setting, either per query or globally for the entire persistence unit. E.g.

<named-query name="User.getAll" caseSensitive="true">
    <query>
        SELECT
            user
        FROM
            User user
    </query>
</named-query>


 Comments   
Comment by c.beikov [ 24/Apr/13 ]

Would it break backwards compatibility? I don't think so.
IMO this is an important addition when there is no reason for not including it. Many developers just use "propritary features" of their persistence providers and don't even know for sure that it isn't standard. I used hibernate ever since and I didn't know JPQL is case insensitive. So if I really want to deploy my applications to servers that do not have hibernate on them and the JPA implementation of the target system is not case sensitive, I would have to rewrite 300+ queries to get it working

Please consider the addition or give reasons for not doing it!

Comment by pbenedict [ 23/Nov/15 ]

Interesting addition. Adding caseSensitive to both the descriptor and @NamedQuery seems sensible, but most queries that I've seen (SQL and JPQL) have standardized on the one letter alias convention. I probably did hit this problem once but it's just too easy to use another alias.





[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

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



 Comments   
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

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

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:

@Embeddable
@Customizer(MyPhysicalCustomizer.class)
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.





[JPA_SPEC-20] add FetchType.LAZY/EAGER to @Lob fields and @Embeddable Created: 10/May/12  Updated: 05/Apr/13

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

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


 Description   

Afaik there is currently no way to specify a @Lob field as being lazy loaded.

BLOBS and LOBS often need a big amount of memory and are expensive to fetch from the database.

What about adding something like:

public class MyEntity {

  @Lob(FetchType.LAZY)
  private String someHistoryData;

}

Currently one always needs to create explicit list objects which get filled with 'new' in JPQL to not trash the database.

The same goes for @Embeddable. Though not needed that desperately it could be useful as well. (The whole Embedded would get lazily fetched when a single attribute of it is read).



 Comments   
Comment by Mark Struberg [ 14/May/12 ]

small note: it's for sure better to define the FetchType in each @Embedded and not in @Embeddable.

Comment by mkeith [ 15/May/12 ]

You can actually combine @Lob with @Basic, allowing you to specify a fetch type for any Lob attribute. I think this will give you what you want.

As far as Embedded objects go, any one of the embedded attributes can be individually specified to be lazy loaded but there is not currently a standard way to say that the embedded object should be lazy loaded as an object. My personal opinion is that if you get to that point then you are probably bordering on considering the embeddable as an independent privately owned entity and should make a relationship out of it instead of an embeddable, but that may just be me. We could get to the stage of adding a fetchType element on @Embedded, or we could handle this case through entity fetch groups.

Comment by ldemichiel [ 15/May/12 ]

I think it is reasonable to add FetchType to @Embedded. When we first introduced embeddables they were more limited in terms of what attributes they could have.

Comment by Mark Struberg [ 20/May/12 ]

Mike, Linda, thanks for pointing me to @Basic. I was actually not aware that I can use both @Basic and @Column on the same field - my fault. I always thought that @Column was a successor of @Basic, mostly because they have conflicting properties. E.g. having a

@Basic(optional=false)
@Column(nullable=true)
private String xxx;

lets me without a clue what should happen. But that is certainly another (minor) problem.

As for FetchType for Embedded fields: this is certainly not as big as an issue for the (now solved) @Lob question. Downgrade to minor? txs!

Comment by ldemichiel [ 30/Oct/12 ]

Downgraded priority to reflect comments





[JPA_SPEC-19] Upload official/standard JPA 2.0 API jar to Maven Central Created: 05/Apr/12  Updated: 05/Oct/15

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

Type: Improvement Priority: Minor
Reporter: Matthew Adams Assignee: ldemichiel
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: bundle, maven, mavenization, osgi, repositories, repository

 Description   

There is no official or standard JPA API jar available from the expert group in either Maven Central or the java.net Maven repo that both JPA users & implementors can utilize. Users are left to search for implementations' groupId, artifactId, & version values, which is inconvenient.

Please upload a binary jar (including class files and relevant resource files), a source jar, and a javadoc jar, under the groupId "javax.persistence", artifact id "jpa-api" and version "2.0". A minimal target Maven repository would be Maven Central, but others like java.net might be nice, too.

Bonus points for including OSGi bundle metadata (pretty easy if using Apache Felix's Maven Bundle Plugin, org.apache.felix:maven-bundle-plugin:2.3.7)!



 Comments   
Comment by Matthew Adams [ 13/Jun/13 ]

http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C6.0%7Cjar

Is this intended to be the release? If so, it might do for some, but a standalone JPA API artifact would be ideal.

Comment by marcelstoer [ 05/Oct/15 ]

The same was requested for JPA 2.1 in JPA_SPEC-60. If the maintainers have no intention of fixing this they should at least close it with 'won't fix' - and ideally give an explanation.





Generated at Tue Aug 30 10:07:51 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.