[hibernate-dev] HHH-2907 : re-purpose org.hibernate.annotations.Generated ?

[Steve Ebersole]

On 10/17/2013 07:24 AM, Gunnar Morling wrote:
>
> I think I'd keep it simple and with one way of specifying the 
> generator and see how it works. If there is demand for the other 
> option it could be added later on.

My concern there is that virtually noone aside from me really 
knows/understands the StrategySelector service and its capabilities, so 
there would be no demand.


>
> Regarding @CreationTimestamp and the like, would this be a fixed set 
> of built-in annotations or do you envision a mechanism which also 
> allows for custom implementations provided by the user?

You mean allowing for custom annotations by looking for annotations 
annotated with our marker annotation?  Its an interesting idea; I had 
not considered it.

The idea for @CreationTimestamp, etal was for a simplified means for the 
most common use-cases (80/20) with @Generated as the fully-configurable 
base.  Although driving this morning I did think some more about the 
general distinction between vm/db.  In the issue, this is the bullet 
point about :

(for source=db) allow specifying whether it is trigger generated or 
whether we need to embed call to the "current timestamp" function

The point there is that in some cases we need to include the column in 
the INSERT/UPDATE column list, other times we do not.  And that's an 
difficult thing to express concisely in the generic @Generator case.

But back to what I think you are suggesting and your example, I will say 
that I did not like the "double meaning" of @Generated.  Plus, as the 
marker applied to another annotation that implies generation I don't 
think it is the correct term.  But TBH I often have difficulty naming 
the metadata for metadata ;)