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 ;) _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
