[hibernate-dev] Envers compile issue

[Łukasz Antoniak]

Hello Steve,

In general Envers does not support formula columns. Probably we should save
formula value to audit table. This can be tricky and I have to think it
over. Copying formula column to audit entity would not produce expected
result in all cases (e.g. time functions used in formula expression).
Currently we support @DiscriminatorFormula annotation without saving its
value to audit table, since entities do not change their type.

@Adam: Thoughts? What do you think about copying formula column to audit
entity directly? Simplest solution AFAIK.

All usages of org.hibernate.mapping.Value#**getColumnIterator(), except the
one in
org.hibernate.envers.configuration.internal.metadata.BasicMetadataGenerator,
map relation properties. IMO it is safe assumption that we are dealing with
columns there.

@Steve: if you agree, feel free to throw an exception if encountered
formula column in BasicMetadataGenerator asking to register new feature.

Best regards,
Lukasz



2013/4/11 Steve Ebersole <steve at hibernate.org>

> One option just came to mind.  Looking at the code, I have to assume
> envers really just does not support formulas.  Otherwise, all these compile
> errors would eventually have resulted in runtime (CCE) exceptions.
>
> If that is really the case, I could add detection of that and throw a more
> meaningful exception.  If that sounds like a reasonable option, just let me
> know and I'll make that change.
>
> Alternatively I could just log a message and keep going, but i don't think
> that's a good choice.
>
>
>
> On Thu 11 Apr 2013 04:07:27 PM CDT, Steve Ebersole wrote:
>
>> I just made a change to help catch runtime problems that kept cropping
>> up.  The change was to org.hibernate.mapping.Value#**getColumnIterator.
>> The problem is that code in many modules (hem, envers) that actually
>> deals with mapping code were making a bad assumption here.  The
>> returned iterator actually returns a Iterable<Selectable>, not
>> Iterable<Column>. Selectable is the contract shared between Column and
>> Formula.  So when code non-defensively tries to treat that thing as a
>> Iterable<Column> we often have issues.
>>
>> Yes, the method is very poorly named.  Actually it predates formula as
>> a feature.  But be that as it may, the code casting those elements to
>> Column are just wrong.
>>
>> For envers, I am not actually sure how to handle Formula elements. I
>> need some help there.  The issues are all isolated to
>> org.hibernate.envers.**configuration.internal.**metadata  Could someone
>> more familiar with envers (and especially its entity definition stuff)
>> take a look?
>>
>> Thanks!
>>
>