talking about
org.hibernate.test.annotations.manytoonewithformula.ManyToOneWithFormulaTest
org.hibernate.test.annotations.manytoonewithformula.ProductSqlServer AND
org.hibernate.test.annotations.manytoonewithformula.Product
these two are exactly same ( has same @Table(name="product") and other
I agree with the unwrap proposal, but I could not get it to work if we
involve Enums. It seems like the user needs to know how to cast, which
is quite ugly.
I don't like the Visitor approach in this case as it requires the user
code to implement a method per type, which means we would break
backwar
Ahh, and I forgot to ask Gunnar whether he thinks the API fits the OGM use case
now?
--Hardy
On 16 Jan 2013, at 11:18 AM, Hardy Ferentschik wrote:
> To give some more context. The split of FieldSettingsDescriptor and
> FieldDescriptor is driven by the
> discussion we had regarding HSEARCH-9
To give some more context. The split of FieldSettingsDescriptor and
FieldDescriptor is driven by the
discussion we had regarding HSEARCH-904 and the extension of the bridge
interface, allowing it
to report the fields it creates. Custom bridges need to create or at least
provide the information
Like gunnar, I was thinking that a type property and an unwrapping
method would do the trick. Though I'd favor delegation over
subclassing.
On Tue 2013-07-16 9:27, Gunnar Morling wrote:
> Hi,
>
> > I won't mention my favorite Vattern. I've considered adding subtypes
> but not liking it as their
Hi,
> I won't mention my favorite Vattern. I've considered adding subtypes
but not liking it as their usage would not be clear from the API.
How would you use your vavorite Vattern without subtypes? And which other
option would you prefer then?
I think the field-type specific information can eit
