that's right, as suggested by Emmanuel I plan to separate the JGroups
Sync/Async options from the worker.execution property so you can play
with the two independently.
I think the JGroups option's default could depend on the backend - if
not otherwise specified, and if we all agree it doesn't make
I think we need more fine-grained config for this new JGroups sync feature.
I added this to our cache config
async
and it broke our tests.
Where previous (old / non JGroups sync) behavior worked.
It of course also works without this async config,
but in this case we do
In the meantime (to get the builds working again) I went ahead and
implemented the explicit checking. If you want to change something
there, just look for usages of the new
org.hibernate.envers.configuration.internal.metadata.FormulaNotSupportedException.
There are only 2 places it is used,
Hi Lukasz,
The problems seem limited to usages of:
1)
org.hibernate.envers.configuration.internal.metadata.MetadataTools#getColumnNameIterator
2)
org.hibernate.envers.configuration.internal.metadata.MetadataTools#addColumns
from:
1)
org.hibernate.envers.configuration.internal.metadata.AuditMe
Hiding behind a long and deep email won't hide the fact that you have not
answered my question :)
More inline.
On Thu 2013-04-11 17:47, Sanne Grinovero wrote:
> Man your simple question is actually super complex.
>
> Conclusion first: I think it's important we can always identify any
> index jus
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 expressi
