ability to apply 'generation strategy' to generated properties
Description
causes
is followed up by
relates to
Activity
Igor Gulco December 7, 2019 at 7:11 PM
This feature is not working for fields that require to be re-generated, such as updated_date.
It also broke the legacy @Generated(ALWAYS) annotation.
This piece of code (or something similar) needs to be added to this method.
Brett Meyer March 7, 2014 at 10:07 PM
Bulk closing tickets resolved in released versions
Steve Ebersole November 11, 2013 at 2:58 PM
I'd prefer moving this to AsciiDoc(tor). What I envision overall is a topical guide on "value generation" that covers both identifier and non-identifier generation.
If you wanted to take a stab at the full thing, that would be great. But really I was just hoping you'd at least help document these new annotations for non-identifier generation.
Gunnar Morling November 11, 2013 at 8:26 AM
Yes, I can do that, Steve. I've created HHH-8692 and assigned to me.
In which way do you envision this, I saw there is a section on @Generated in the development guide which could be extended, but we could also create a topical guide on this using the new AsciiDoc approach.
Steve Ebersole November 8, 2013 at 7:13 PM
Thanks for that Gunnar.
Going to close this now. The one thing we should do is to write a guide about "value generation". Would you mind helping out with that Gunnar based on the annotation work you did?
Currently, the support for generated properties allows only for db-generated values (ala triggers etc). Would be great to allow the user to provide a seperate (optional) strategy for generating the generated values.
It would be nice to have a generic solution, which we can build on top of for the more common use cases. Also, we may need to use a name other than 'generated' in the annotations to avoid conflicts with the current @Generated annotation; for now lets use the term @Dynamic.
Consider mapping a 'created timestamp' column. Currently, provided we are using a trigger, that would look like:
@Generated(INSERT) Date created;
The strategy here (^^) is implicitly 'db', as the db is taking care of the generation. In the most generic form, that could be written as:
@Dynamic(time=INSERT,strategy=DB) Date created;
Additionally, since this is such a common case, also allow this:
@CreationTimestamp Date created;
The final form would also allow the definition of strategies. As an example, consider:
@CreationTimestamp(strategy=NOW) Date created;
Here we are not relying on the db to generate the value, but are explicitly telling Hibernate to do it (basically 'use the current timestamp to generate a value here whenever we do an insert').