Yes, but the more important point to me is whether the problem here really
is the classic translator or envers.
Just look at the API call you posted:
getAuditReader().find( IntTestEntity.class, id1, 1 )
Why should that be dependent on the HQL translator used? Since envers
creates the HQL it see
the failing test is testHistoryOfId1,
and the query is executed inside the assert method by getAuditReader().find(
IntTestEntity.class, id1, 1 )
notice that if you run directly the
org.hibernate.envers.test.integration.basic.Simple
class that org.hibernate.envers.test.integration.basic.
ClassicQue
This test was originally added for
https://hibernate.atlassian.net/browse/HHH-8497
I guess my first thought is to question is why this test exists at all.
It's really a question of whether we consider the classic HQL translator
"supported". Stuff like this "parameter expected type" was developed
> On 03 Jun 2015, at 04:37, Steve Ebersole wrote:
>
> I am needing to change how "property access" is handled (as in the
> org.hibernate.property package). I have no idea how to fit that into
> Envers and specifically into its ReflectionTools class. The problems boil
> down to org.hibernate.en
I just want to make sure this is consistent across uses. What are the
rules for Audited, MappedSuperclass and Entity? IMO, that is what should
happen for Audited, MappedSuperclass and Embeddable as well. Are those
consistent?
Adam, what specifically is complicated by supporting AO paths? Is it
Hi Adam,
Currently, the ways to enable auditing on a mapped-superclass that we
discussed below do not work when an embeddable class has no declared data. The
only way I can find to enable auditing for the mapped-superclass is to annotate
the embeddable class with @Audited.
For example:
@Enti
Sorry, no idea why I missed that email.
So the basic rule is:
- fields from a non-audited mapped superclass are never audited, unless an
@AuditOverride is specified
- if the mapped superclass is audited, then its fields are of course audited as
well
I don’t think we want to get into supporting
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
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
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 meaning
I had forgotten that I actually had already wired this in... The
contract you want is
org.hibernate.metamodel.spi.AdditionalJaxbRootProducer:
public interface AdditionalJaxbRootProducer {
/**
* Produce and return the list of additional mappings to be processed.
*
It wont be via Integrator. This is the same discussion you and I had
with Max wrt tooling. I'll ping you when Jandex is available for use by
Envers (I'll take care of all the wiring). Hopefully should be done
tomorrow or the day after.
On 09/08/2012 05:37 AM, Łukasz Antoniak wrote:
> Hello H
Hello Hardy,
Thank you for the clarification. This is what I thought initially by
looking at the code. I have reviewed the relevant mailing list topic,
and would agree that Jandex repository should be passed to integrator
somehow. Other Hibernate extensions probably introduce custom
annotations as
Should have mentioned to look at Index, ClassInfo and AnnotationInstance to get
a feel for the Jandex API. You find the Jandex project on Github -
https://github.com/jbossas/jandex. I don't think there is a project website yet.
--hardy
On 7 Sep 2012, at 22:05, Łukasz Antoniak wrote:
> Hello
Hi Lukasz,
The metamodel branch makes use of Jandex which is a sort of a annotation
repository/index (used also by AS). All annotated classes get added to this
index. I would expect that Envers uses this as well. Either by creating its own
Jandex index (probably not so good idea) or by reusing
Hello Steve,
Just wanted to let you know that I am trying to migrate Envers to new
metamodel. I have asked below question on IRC, but without any
response. At the moment Envers locates its annotations (for example
@Audited) using ReflectionManager. What would be the preferable way of
achieving thi
Lukasz, as always, any help you can give is appreciated! Whenever you
have time. We have a temporary solution that will isolate needed
changes to just Envers. Basically the changes at some point will be
using the JAXB binding model rather than DOM.
On Fri 24 Aug 2012 01:55:55 AM CDT, Łukasz
Hello Steve,
I think I could start working on metamodel branch at the beginning of
September. Is it acceptable for you? I don't want to
postpone 4.1.7 release. JIRA task has been already registered:
https://hibernate.onjira.com/browse/HHH-7490.
Best Regards,
Lukasz
__ Information fro
Honestly, I'd prefer it build a JAXB model. As is there would be
unnecessary overhead to bind the DOM model to the JAXB model. Plus, on
the producer side (envers) it gives type-safety.
But of course this requires changing how envers builds its metamodel.
Adam, Lukasz, is this something y'all
On Aug 22, 2012, at 8:11 AM, Steve Ebersole wrote:
> Also, I think how you were expecting beforeMetadataProcessing to happen can't
> really happen, but I suspect it is the more direct way to port envers.
>
> I *think* what you were thinking is to have envers pass along its extra
> EntitySourc
Well, yes, given that they are split that way I will agree there is
probably not a way in IntelliJ to run individual methods.
On Tue 27 Mar 2012 09:48:15 AM CDT, Adam Warski wrote:
> I think you usually need to run the whole class as the first method setups
> the data, and the other methods read
I think you usually need to run the whole class as the first method setups the
data, and the other methods read history.'
So you would always need to run at least 2. And I think that's not possible in
Idea.
Adam
On Mar 26, 2012, at 9:06 PM, Steve Ebersole wrote:
> Ok, I figured it out for whol
Ok, I figured it out for whole test classes. I assume then that it is
not possible to run single test methods?
On Mon 26 Mar 2012 06:31:46 PM CDT, Steve Ebersole wrote:
> Anyone know the magic incantation to get Envers tests to run in IntelliJ?
>
--
st...@hibernate.org
http://hibernate.org
___
Me neither - auto-registration by putting the jar on the classpath is a bit too
much magic.
So I would make this "bulk registration" (maybe auto is not the best way then)
off by default (for envers and any other hibernate module)
Adam
On Sep 13, 2010, at 3:48 PM, Steve Ebersole wrote:
> I am
On Sep 15, 2010, at 15:07, Steve Ebersole wrote:
> Here is my issue with that line of thought... Many of these listeners
> alter the things you want to query!
yes, for envers querying could be different I guess but for Search it is not.
And none of them should affect the reverse engineering si
Here is my issue with that line of thought... Many of these listeners
alter the things you want to query!
On Wed, 2010-09-15 at 10:44 +0200, Andersen Max wrote:
> note, this is not just all about osgi but more about it not making sense (or
> causes conflicts) to run with hibernate search and env
note, this is not just all about osgi but more about it not making sense (or
causes conflicts) to run with hibernate search and envers enabled
when the only thing you want to do is to run a query or introspect the
Configuration/SessionFactory object.
/max
On Sep 14, 2010, at 16:47, Steve Ebers
On Sep 14, 2010, at 16:47, Steve Ebersole wrote:
> "osgi land" in general is a problem.
>
> But yeah, I had even added a comment in this code that really we need to
> allow passing in the ClassLoader to use. In fact this is not osgi
> specific. In general JPA says we should use a specific Cl
"osgi land" in general is a problem.
But yeah, I had even added a comment in this code that really we need to
allow passing in the ClassLoader to use. In fact this is not osgi
specific. In general JPA says we should use a specific ClassLoader for
these lookups in JEE deployments, namely the on
If this is done please make it super easy to disable that behavior - i.e. I
don't want envers, search nor validator to be enabled by default when I run
queries or reverse engineering from within tooling.
i.e. I believe Search has a property to disable the behavior which we use to
avoid classloa
Is anyone aware of a current, valid use-case of allowing the same
listener class to be registered multiple times for the same event? I
know we have many "multi-faceted listeners that listen for many events.
Thats not what I mean. I mean, is there ever a time anyone can think of
when something lik
I am not a fan of this. For a number of reasons.
First this means added complexity to manage the list of listeners in
regards to (1) not over-writing any explicitly registered listeners and
(b) not duplicating listeners.
Second keep in mind that the hibernate3.jar from the release
distribution
I would favor such model ie. an automatic event registration when the lib is in
the classpath.
We could generalize that actually to let any lib to register its event
listeners (maybe something a la service locator).
Today Search and Validator have a specific hook in Core.
On 11 sept. 2010, at 09
Sure. I wasn't proposing not allowing users to register listeners at
all, whether it be the supplied envers listeners, the supplied search
ones, or some custom ones. That is core Hibernate functionality to
allow users to be able to do this. No, this would merely be a new flag
users could use *in
Adam is right! Sometimes the envers default listeners are overriden by user
custom listeners.
2010/9/11 Adam Warski
> Sounds great. I think that there may be on option to automatically add all
> the appropriate listeners, but the users would still have the possibility to
> add them by hand (in
Sounds great. I think that there may be on option to automatically add all the
appropriate listeners, but the users would still have the possibility to add
them by hand (in the more advanced use-cases, but that will probably be rare).
Same applies to the HSearch listeners I suppose.
On Sep 10,
In Search and Validator we enable the listeners when we detect Search res.
Validator on the classpath (with an option
to explicitly not enable it). Maybe we could do the same with Envers?
--Hardy
On Fri, 10 Sep 2010 20:40:04 +0200, Steve Ebersole
wrote:
> What do you think of an option that
Well there is also a possibility in this case that we whack a users set
of custom listeners. Or if they define listeners that short-circuit
event processing before envers listeners are processed (assuming we
append the envers listeners to the end of the listeners list).
On Fri, 2010-09-10 at 15:4
Hello!
I think it´s a good idea. There would be fewer user errors setting up
envers.
Regards. Hernán.
2010/9/10 Steve Ebersole
> What do you think of an option that says "enable envers", rather than
> explicitly needing to set up each listener?
>
> --
> Steve Ebersole
> http://hibernate.org
Next Wed is the deadline.
On 21 janv. 2010, at 16:40, Hardy Ferentschik wrote:
>
> We will have to do a release of the metamodel generator either way before
> the next Core release.
> If possible I would like to wait a couple of days though. I wanted to look
> into some simple issues
> like
We will have to do a release of the metamodel generator either way before
the next Core release.
If possible I would like to wait a couple of days though. I wanted to look
into some simple issues
like METAGEN-14 for the next version.
Will there be a Beta4 version of Core? And if so when?
--H
Perhaps we should consider a release of the generator
-- Sent from my Palm Pre
st...@hibernate.org
http://hibernate.orgEmmanuel Bernard wrote:
This is a bug I've found a couple of weeks ago on the generator while
investigating the Envers test errors.
Be sure to use the latest snapshot of jpam
svn update from this morning
No Envers failure.
On 21 janv. 2010, at 05:01, Steve Ebersole wrote:
> Anyone else seeing lots of failures in envers tests? I am getting this
> even after a full update.
>
> Just trying to see if I have a local issue with maven repo, etc.
>
> --
> Steve Ebersole
This is a bug I've found a couple of weeks ago on the generator while
investigating the Envers test errors.
Be sure to use the latest snapshot of jpamodelgen (or build it yourself). And
be sure entitymanager uses it too.
On 21 janv. 2010, at 05:19, Steve Ebersole wrote:
> Actually having an is
Actually having an issue b4 that in attempts to get a full clean build,
in entitymanger with the metamodel generator:
[INFO] Compilation failure
/home/steve/projects/hibernate/core/trunk/entitymanager/target/generated-src/jpamodelgen/org/hibernate/ejb/test/metadata/Relatives_.java:[10,55]
cannot
I know, but I still like it ;)
/max
Generally annotations on an entity are describing a quality of the
entity, whereas a lot of these suggestions are describing actions to be
done with or on behalf of the entity (e.g., its @Entity not
@StoreInDatabase, its @Version not @UseToOptimisticlyLock, i
The term 'audit' here is fairly well excepted in our field to mean
exactly what we are talking about here.
And besides, you cant use the dictionary to dismiss one possibility in
favor of another that does not even exist in the dictionary ;)
-
Steve Ebersole
Project Lead
http://hibernate.org
Generally annotations on an entity are describing a quality of the
entity, whereas a lot of these suggestions are describing actions to be
done with or on behalf of the entity (e.g., its @Entity not
@StoreInDatabase, its @Version not @UseToOptimisticlyLock, its @Id not
@TrackIdentifierValue, etc).
I like @TrackHistory
/max
@KeepHistory sounds well, it's straightforward to what it's going to do.
I was thinking about @TrackChanges but you aren't really building
"diff"s,
so "history": @TrackHistory or @KeepHistory ?
still including some flavour of the "version" should be better IMHO,
a
On Oct 24, 2008, at 22:22, Elias Ross wrote:
On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
<[EMAIL PROTECTED]> wrote:
@StoreHistory
@KeepHistory
I probably like @Audited better though.
@Historized sounds computer science-y and pretty cool. @Chronicled is
also pretty cool sounding.
"Au
@KeepHistory sounds well, it's straightforward to what it's going to do.
I was thinking about @TrackChanges but you aren't really building "diff"s,
so "history": @TrackHistory or @KeepHistory ?
still including some flavour of the "version" should be better IMHO,
as every programmer
has some knowl
On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
<[EMAIL PROTECTED]> wrote:
> @StoreHistory
> @KeepHistory
>
> I probably like @Audited better though.
@Historized sounds computer science-y and pretty cool. @Chronicled is
also pretty cool sounding.
"Audit" is right out. It means: "1 a: a formal e
@StoreHistory
@KeepHistory
I probably like @Audited better though.
--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com
| http://twitter.com/emmanuelbernard
Hibernate Search in Action (http://is.gd/Dl1)
On Oct 24, 2008, at 06:59, Adam Warski wrote:
Hello,
I'd say either @Audited or @Historized. @Audited sounds more
"natural"
to me, but like I said above I think @Historized is more "correct".
the dictionary has a similar word - historicized - that me means to
"render historic".
But having a @Historicized annotation doesn't seem very
The idea, moving forward, is to start pushing the Annotations approach
more than we do now. Not to deprecate xml mappings per-se but certainly
to start looking at Annotations as the preferred approach. At that
point we'd stop developing the HbmBinder code (aside from bug fixes).
Note that this is
Yes I think it will really lead to confusion.
Deprecation seems reasonable. So lets get this migrated for Hibernate's
3.4/3.5 release with the deprecations noting removal in 4.0.
-
Steve Ebersole
Project Lead
http://hibernate.org
[EMAIL PROTECTED]
Principal Software Engineer
JBoss, a divisio
You can still target just Annotation/EntityManager environments if you
want. Nothing in this move precludes that because Annotations and
EntityManager themselves will be doing similar moves.
-
Steve Ebersole
Project Lead
http://hibernate.org
[EMAIL PROTECTED]
Principal Software Engineer
JBoss
I'm really in-between on this naming actually.
I think 'historize' is the correct term for what envers does. But since
'historize' is not a real dictionary word I am nervous to use it in the
actual annotation (though google shows that it is indeed a well
used/understood computer engineering term
This is exactly what we discussed yesterday on IRC.
-
Steve Ebersole
Project Lead
http://hibernate.org
[EMAIL PROTECTED]
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Wed, 2008-10-22 at 19:48 -0400, Emmanuel
On Oct 23, 2008, at 07:18, Adam Warski wrote:
I can see the confusion. Hibernate has a similar annotation for
optimistic locking which nearly matches "Versioned" in Envers.
Yes, @Version. But it's for a totally different thing. So far I
only once I had a question on the forum if @Versioned
Adam Warski wrote:
> Hello,
>
>>> Though I'd have to do some adaptation changes. As I was originally
>>> targeting Envers to support JPA mappings, I assumed that it will be
>>> working in an enviroment with Hibernate Annotations/EntityManager. So
>>> I used ReflectionManager to read the @Versioned
Hello,
Though I'd have to do some adaptation changes. As I was originally
targeting Envers to support JPA mappings, I assumed that it will be
working in an enviroment with Hibernate Annotations/EntityManager.
So I used ReflectionManager to read the @Versioned annotations. In
a pure Hibern
Hello,
I can see the confusion. Hibernate has a similar annotation for
optimistic locking which nearly matches "Versioned" in Envers.
Yes, @Version. But it's for a totally different thing. So far I
only once I had a question on the forum if @Versioned and @Version
are related in any way. Do
Hi,
On Thu, 23 Oct 2008 12:17:18 +0200, Adam Warski <[EMAIL PROTECTED]> wrote:
Though I'd have to do some adaptation changes. As I was originally
targeting Envers to support JPA mappings, I assumed that it will be
working in an enviroment with Hibernate Annotations/EntityManager. So I
used
I can see the confusion. Hibernate has a similar annotation for
optimistic locking which nearly matches "Versioned" in Envers.
Yes, @Version. But it's for a totally different thing. So far I only
once I had a question on the forum if @Versioned and @Version are
related in any way. Do you reall
Hello,
I wonder if it really has to be a project on its own?
A module in core would make more sense?
I wouldn't have anything against :)
Though I'd have to do some adaptation changes. As I was originally
targeting Envers to support JPA mappings, I assumed that it will be
working in an envi
Hi,
On Thu, 23 Oct 2008 10:42:45 +0200, Adam Warski <[EMAIL PROTECTED]> wrote:
I can see the confusion. Hibernate has a similar annotation for
optimistic locking which nearly matches "Versioned" in Envers.
Yes, @Version. But it's for a totally different thing. So far I only
once I had a quest
Hello,
I can see the confusion. Hibernate has a similar annotation for
optimistic locking which nearly matches "Versioned" in Envers.
Yes, @Version. But it's for a totally different thing. So far I only
once I had a question on the forum if @Versioned and @Version are
related in any way. Do
I wonder if it really has to be a project on its own?
A module in core would make more sense?
--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com
| http://twitter.com/emmanuelbernard
Hibernate Search in Action (http://is.gd/Dl1)
On Oct 21, 2008, at 1
I can see the confusion. Hibernate has a similar annotation for
optimistic locking which nearly matches "Versioned" in Envers.
Some "Version"-free class naming ideas:
RevisionListener
VersionsReader -> RevisionReader | HistoryReader
Classes
DefaultRevisionEntity
VersionsReaderFactory -> RevisionR
I think the "plug in the way versioned data is stored" bit accounts for
what I meant :)
Also I suggest that you move away from the term "versioning" here. This
is already:
1) over-used/over-loaded
2) used by the JPA spec to mean optimistic locking.
Really this is "auditing" or "capturing histori
Hello,
One thing I would like to see in adition is the ability to store
flattened audting of changes. There are many examples of such a thing
on the wiki and the web at large.
yes, that's one of the points on my roadmap - "support for different
versioning schemes" (provided I have the time to
I'd say yes most definitely...
One thing I would like to see in adition is the ability to store
flattened audting of changes. There are many examples of such a thing
on the wiki and the web at large.
-
Steve Ebersole
Project Lead
http://hibernate.org
[EMAIL PROTECTED]
Principal Software Engi
But, as the logical place to do this would be in hibernate, this
brings the question: would you (= the Hibernate team) be interested
in Envers and in me developing it further? :)
I'll take the lack of answers as a no :) But thanks, Max and Sanne :)
Meanwhile, maybe it will interest some of yo
I'm just a contributor for Search, but if you may be interested in
my opinion:
we released software yesterday in production which uses Envers 1.0GA
and it's really being useful.
Great to know it's being used :)
And I learned in some minutes how to use it :-)
So if I could vote I would defin
I'm just a contributor for Search, but if you may be interested in my opinion:
we released software yesterday in production which uses Envers 1.0GA
and it's really being useful.
And I learned in some minutes how to use it :-)
So if I could vote I would definitely make it "officially" part of Hibe
I for one would like to have something like Envers for Hibernate ;)
/max
Hello,
currently I'm a working for the jboss.org team, but as you maybe
remember I also created the Envers project (http://www.jboss.org/
envers/). I would like to change my scope of work a bit and work
"officialy" o
On Sep 11, 2008, at 07:16, Adam Warski wrote:
Also Emmanuel has added "autoregistration" of listeners
for when Search is on classhpath during the EntityManager
factory startup; IMHO it would be nice to register this one
in the same way.
As far as I remember, the autoregistration is done by ch
Hello,
this is looking very promising, congratulations for the slides too
they made me understand it well without needing explanations.
Thanks :)
I am seeing many similarities with Hibernate Search,
maybe it is possible to reuse the annotations (and/or code)
of it for your upcoming "support f
Hello,
this is looking very promising, congratulations for the slides too
they made me understand it well without needing explanations.
I am seeing many similarities with Hibernate Search,
maybe it is possible to reuse the annotations (and/or code)
of it for your upcoming "support for persistent c
81 matches
Mail list logo
