That's talking about @PostPersist. I though I might have read over something that mandates the identifiers not being available in @PrePersist, which — if it was present — would turn your request into a breaking change.
I am assuming that's your ticket here [0]? If that's the case, I guess all we can do is wait and hope for good news at JavaOne :).
Cheers,
Ollie
[0]
https://java.net/jira/browse/JPA_SPEC-133
> Am 16.08.2016 um 14:24 schrieb Jin Kwon <jinahya_at_gmail.com>:
>
> Please look again. The last sentence of the paragraph
>
> JSR338/3.5.3 specified that
> Generated primary key values are available in the PostPersist method.
>
>
> On Tuesday, 16 August 2016, Oliver Gierke <ogierke_at_pivotal.io> wrote:
> Agreed, I just thought it might be helpful to get something fixed before 2018 :).
>
> When you write "follow the specification", do you imply that there's a place in the spec that clarifies on that scenario? I just found 3.5.3, which doesn't state anything regarding identifier population in/for lifecycle callbacks.
>
> Cheers,
> Ollie
>
> > Am 16.08.2016 um 13:56 schrieb Jin Kwon <jinahya_at_gmail.com>:
> >
> > Relying on implementation-specific behavior is not good. I actually faced the hazard. GlassFish(Eclipselink) assigned the id before @PrePersist while WildFly(Hibernate) seems decided to follow the specification.
> > On 2016년 8월 16일 (화) at 20:50 Oliver Gierke <ogierke_at_pivotal.io> wrote:
> > I see, that certainly makes sense. Generally speaking I don't see anything in the spec that should prevent implementors from behaving just the way you asked. Have you checked whether any of the persistence providers currently already behaves that way? I assume you might have more luck getting that feature implemented asking there first given that there's hardly any movement in JPA.next currently.
> >
> > > Am 16.08.2016 um 13:24 schrieb Jin Kwon <jinahya_at_gmail.com>:
> > >
> > > @Oliver
> > > When GenerationType.TABLE used,
> > > AS should fetch and prepare some ID values (by TableGenerator#allocationSize) regardless entity lifecycle
> > > and assign one of them for each entity.
> > > That's the very different feature against IDENTITY/SEQUENCE which each has to insert first and read the engine-generated(assigned) value.
> > >
> > > On Tue, Aug 16, 2016 at 7:47 PM, Oliver Gierke <ogierke_at_pivotal.io> wrote:
> > > Hi Jin,
> > >
> > > I might be missing something obvious here but @PrePersist effectively implies *before* any database interaction. So how can the database generated be available at this time already?
> > >
> > > Cheers,
> > > Ollie
> > >
> > > > Am 09.08.2016 um 11:26 schrieb Jin Kwon <jinahya_at_gmail.com>:
> > > >
> > > > JSR338/3.5.3 specified that
> > > >
> > > > Generated primary key values are available in the PostPersist method.
> > > >
> > > > Is it possibly to specify TABLE-generated IDs available on PrePersist?
> > > >
> > > > e.g.
> > > > public class MyEntity {
> > > >
> > > > @PrePersist
> > > > private void onPrePersist() {
> > > > // make derived as a unique value derived from the id
> > > > derived = String.format("%016x", id);
> > > > }
> > > >
> > > > @GeneratedValue(..., strategy = GenerationType.TABLE)
> > > > @Id
> > > > private Long id;
> > > >
> > > > @Column(..., nullable = false, updatable = false)
> > > > private String derived;
> > > > }
> >
>
> --
> /**
> * @author Oliver Gierke - Senior Software Engineer
> *
> * @param email ogierke_at_pivotal.io
> * @param phone +49-151-50465477
> * @param fax +49-351-418898439
> * @param skype einsdreizehn
> * @see http://www.olivergierke.de
> */
>
--
/**
* @author Oliver Gierke - Senior Software Engineer
*
* @param email ogierke_at_pivotal.io
* @param phone +49-151-50465477
* @param fax +49-351-418898439
* @param skype einsdreizehn
* @see http://www.olivergierke.de
*/