I think we should simply use a @o.h.a.Columns annotation to embed
@o.h.a.Column annotations and place them on the same property the
@j.p.Column is described.
@Column(name="foo")
@o.h.a.Column(appliesTo="foo", wrap="nsacrypt(?)")
public String getPassword() { ... }
@AttributeOverride(name="street1", colu...@column(name="foo"))
@o.h.a.Column(appliesTo="foo", wrap="nsacrypt(?)")
public Address getHome() {};
We have two solutions:
- reuse @o.h.a.Columns and add
o.h.a.Column[] specialize() default {};
mark columns as default {}; and deal with that in the code (today
someone mapping @Columns() would not work so well).
- create an entirely new annotation @o.h.a.SpecializedColumns
specialized is too long though, a smaller name would greatly help
On 23 sept. 09, at 18:40, Rob Hasselbaum wrote:
> I'm working on an patch to expose HHH-272 functionality (custom
> column read and write expressions).in Annotations. At Steve and
> Emmanuel's request, I'm doing this by creating a new @o.h.a.Column
> annotation to supplement the @javax.persistence.Column annotation,
> similar to what's in place today for @Table. This will allow for
> future extension beyond this one use case, eventually.
>
> It's getting a bit dicey, though, because of the variety of places
> @j.p.Column can show up--for example, inside @AttributeOverride and
> @Columns. The question is how best to embed the companion
> @o.h.a.Column instances in these contexts. Create a
> @o.h.a.AttributeOverride and @o.h.a.AttributeOverrides? A totally
> separate grouping mechanism? It's a little easier with @Columns
> because that's already in the org.hibernate namespace hierarchy, so
> it can be modified. Thoughts?
>
> -Rob
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
