4:05 a.m.
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" on Envers. 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? :)
The three main areas in which I would like to develop in Envers are:
- completing support for JPA mappings: joined and table-per-class
inheritance (the rest works already, as far as I know)
- adding support for hibernate-annotations specific mappings - for
example collections of components, relations in components
- integration with Hibernate Search - to enable indexing and searching
of history of an entity
- support for different versioning schemes - like storing only the
fields that changed, instead of the whole entity
- and of course anything else that you suggest :)
--
Adam
4:12 a.m.
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" on Envers. 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? :)
The three main areas in which I would like to develop in Envers are:
- completing support for JPA mappings: joined and table-per-class
inheritance (the rest works already, as far as I know)
- adding support for hibernate-annotations specific mappings - for
example collections of components, relations in components
- integration with Hibernate Search - to enable indexing and searching
of history of an entity
- support for different versioning schemes - like storing only the
fields that changed, instead of the whole entity
- and of course anything else that you suggest :)
--
/max
6:17 a.m.
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 Hibernate.
Sanne
2008/10/17 Max Rydahl Andersen <max.andersen(a)redhat.com>:
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" on Envers. 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? :)
>
> The three main areas in which I would like to develop in Envers are:
> - completing support for JPA mappings: joined and table-per-class
> inheritance (the rest works already, as far as I know)
> - adding support for hibernate-annotations specific mappings - for example
> collections of components, relations in components
> - integration with Hibernate Search - to enable indexing and searching of
> history of an entity
> - support for different versioning schemes - like storing only the fields
> that changed, instead of the whole entity
> - and of course anything else that you suggest :)
>
--
/max
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:47 p.m.
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 definitely make it "officially" part of
Hibernate.
Maybe I'll setup a poll in clearspace ;)
Adam
1:41 p.m.
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 you, I've just released
Envers 1.1.0.GA. The main new features are the possibility to version
most types of relations and persistent collections and an improved
revisions-of-entities query; you can now read the history of an entity
along with revisions metadata in a single query.
More details on the blog: http://www.warski.org/blog/?p=20 and the
website: http://www.jboss.org/envers/
--
Adam
2:09 p.m.
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
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Tue, 2008-10-21 at 20:41 +0200, Adam Warski wrote:
> 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 you, I've just released
Envers 1.1.0.GA. The main new features are the possibility to version
most types of relations and persistent collections and an improved
revisions-of-entities query; you can now read the history of an entity
along with revisions metadata in a single query.
More details on the blog: http://www.warski.org/blog/?p=20 and the
website: http://www.jboss.org/envers/
2:07 a.m.
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 implement it, of
course :) ). The idea is quite simple - you would be able to plug in
the way versioned data is stored, but access it using the same
interface (VersionsReader).
The versioning scheme that I wanted to add would just store entity
name + entity id + field name + field value combinations. This would
effectively be a simple audit log. Is it what you meant? You could
then access the data as before (with VersionsReader.find, for
example), except that you wouldn't be able to execute queries.
--
Adam
8:36 a.m.
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 historical data".
If you use IRC, perhaps we could chat about the specifics of pulling
your code into the Hibernate svn? irc.freenode.org -> #hibernate-dev
-
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Wed, 2008-10-22 at 09:07 +0200, Adam Warski wrote:
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 implement it, of
course :) ). The idea is quite simple - you would be able to plug in
the way versioned data is stored, but access it using the same
interface (VersionsReader).
The versioning scheme that I wanted to add would just store entity
name + entity id + field name + field value combinations. This would
effectively be a simple audit log. Is it what you meant? You could
then access the data as before (with VersionsReader.find, for
example), except that you wouldn't be able to execute queries.
5:17 p.m.
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 -> RevisionReaderFactory | HistoryReaderFactory
Enums
ModificationStore
RevisionType
Annotation Types
RevisionEntity
RevisionNumber
RevisionTimestamp
SecondaryVersionsTable -> SecondaryRevisionsTable | SecondaryHistoryTable
SecondaryVersionsTables
Unversioned -> Unrevised | Untracked ?
Versioned -> Revised | Historical
VersionsJoinTable -> RevisionJoinTable | HistoryJoinTable
VersionsTable -> RevisionTable | HistoryTable
Envers -> Enrise -> Enhist ?
On Wed, Oct 22, 2008 at 6:36 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
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 historical data".
If you use IRC, perhaps we could chat about the specifics of pulling
your code into the Hibernate svn? irc.freenode.org -> #hibernate-dev
-
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Wed, 2008-10-22 at 09:07 +0200, Adam Warski wrote:
> 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 implement it, of
> course :) ). The idea is quite simple - you would be able to plug in
> the way versioned data is stored, but access it using the same
> interface (VersionsReader).
>
> The versioning scheme that I wanted to add would just store entity
> name + entity id + field name + field value combinations. This would
> effectively be a simple audit log. Is it what you meant? You could
> then access the data as before (with VersionsReader.find, for
> example), except that you wouldn't be able to execute queries.
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
3:42 a.m.
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 you really think it creates confusion?
Some "Version"-free class naming ideas:
RevisionListener
VersionsReader -> RevisionReader | HistoryReader
The "RevisionXXX"
names would suggest that it's for reading revision
data, so revision entities, not the acutal historic data. If at all,
"HistoryXXX" seems much better (HistoryReaderFactory,
SecondaryHistoryTable, HistoryTable, HistoryJoinTable).
If there would be a name change, then the old classes/annotations
should be deprecated, not removed - people wouldn't want to see their
code broken after upgrading to a newer version.
Unversioned -> Unrevised | Untracked ?
Versioned -> Revised | Historical
There was also the idea of
"Historized" :) Then also: Unhistorized.
VersionsJoinTable -> RevisionJoinTable | HistoryJoinTable
VersionsTable -> RevisionTable | HistoryTable
Envers -> Enrise -> Enhist ?
I would keep the current name, people got used
to it :) And it doesn't
directly suggest anything with versioning.
Adam
4:05 a.m.
Hi,
On Thu, 23 Oct 2008 10:42:45 +0200, Adam Warski <adam(a)warski.org> 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 and @Version are
related in any way. Do you really think it creates confusion?
I go with Steve here. I think 'Version' is really overloaded and there
will be
confusion between @Version and @Versioned, especially if they go into the
same code base.
Peronally, I consider the JPA @Version a bad name choice, but that cannot
be changed.
I also agree with Steve that auditing seems to be the right word. I was
several
times asked whether Hibernate supports auditing and when I asked what they
mean they
explained to me pretty much what Envers does.
If there would be a name change, then the old classes/annotations
should
be deprecated, not removed - people wouldn't want to see their code
broken after upgrading to a newer version.
That depends on the already existing userbase. Just deprecating the
annotation might still
lead to confusion since it will be available at eg code completion. In my
opinion a clean start
would be nicer.
--Hardy
6:18 a.m.
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 you really think it creates confusion?
I go with Steve here. I think 'Version' is really overloaded and
there will be
confusion between @Version and @Versioned, especially if they go
into the same code base.
Peronally, I consider the JPA @Version a bad name choice, but that
cannot be changed.
Ok then :). @Historized? @Historic?
I also agree with Steve that auditing seems to be the right word. I
was several
times asked whether Hibernate supports auditing and when I asked
what they mean they
explained to me pretty much what Envers does.
I guess "auditing" is more
commonly understood as storing "flat"
history, as Steve earlier mentioned; that is, you store in a single
table (or tables, the important thing is that the audit tables schema
does not depend on your schema) tuples of entity name, entity id,
field name, field value. It's more space efficient but harder to read
and rather impossible to query. But I'd like to add it as an
alternative VersionsReader, so that users can choose between the two
implementations, whatever suites them better.
> If there would be a name change, then the old classes/annotations
> should be deprecated, not removed - people wouldn't want to see
> their code broken after upgrading to a newer version.
That depends on the already existing userbase. Just deprecating the
annotation might still
lead to confusion since it will be available at eg code completion.
In my opinion a clean start
would be nicer.
As I said - so far users don't seem to be confused (or they
are, but
don't show it :) ). Clean starts are nice but can anger the users ;).
Maybe in the 1.x series the @Versioned could be deprecated and the
annotation (whatever the name) preferred, and the 2.x series would
only have the new one. (Version 2.0 of Envers is where I want to add
the alternative VersionsReader implementation).
--
Adam
9:16 a.m.
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 and @Version
>> are related in any way. Do you really think it creates confusion?
>
> I go with Steve here. I think 'Version' is really overloaded and
> there will be
> confusion between @Version and @Versioned, especially if they go
> into the same code base.
> Peronally, I consider the JPA @Version a bad name choice, but that
> cannot be changed.
Ok then :). @Historized? @Historic?
@Audited
@Archived
9:56 a.m.
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).
I'd say either @Audited or @Historized. @Audited sounds more "natural"
to me, but like I said above I think @Historized is more "correct".
-
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Thu, 2008-10-23 at 10:16 -0400, Emmanuel Bernard wrote:
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 and @Version
>>> are related in any way. Do you really think it creates confusion?
>>
>> I go with Steve here. I think 'Version' is really overloaded and
>> there will be
>> confusion between @Version and @Versioned, especially if they go
>> into the same code base.
>> Peronally, I consider the JPA @Version a bad name choice, but that
>> cannot be changed.
> Ok then :). @Historized? @Historic?
@Audited
@Archived
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:59 a.m.
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 user-friendly.
So I guess we'll stay with @Audited. It's not perfect, but it's a good
compromise :).
--
Adam
7 p.m.
@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 user-friendly.
So I guess we'll stay with @Audited. It's not perfect, but it's a
good compromise :).
--
Adam
9:22 p.m.
On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> 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 examination of an
organization's or individual's accounts or financial situation b: the
final report of an audit 2: a methodical examination and review" ..
You're not examining anything, really you're remembering.
4 a.m.
@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 knowleger of version tracking ( I hope for them at least).
@KeepVersions @TrackVersions @VersioningControlled ?
2008/10/25 Elias Ross <genman(a)noderunner.net>:
On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> 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 examination of an
organization's or individual's accounts or financial situation b: the
final report of an audit 2: a methodical examination and review" ..
You're not examining anything, really you're remembering.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:09 a.m.
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,
as every programmer
has some knowleger of version tracking ( I hope for them at least).
@KeepVersions @TrackVersions @VersioningControlled ?
2008/10/25 Elias Ross <genman(a)noderunner.net>:
> On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
> <emmanuel(a)hibernate.org> 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 examination of an
> organization's or individual's accounts or financial situation b: the
> final report of an audit 2: a methodical examination and review" ..
> You're not examining anything, really you're remembering.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
/max
8:44 a.m.
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).
-
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Mon, 2008-10-27 at 10:09 +0100, Max Rydahl Andersen wrote:
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,
> as every programmer
> has some knowleger of version tracking ( I hope for them at least).
>
> @KeepVersions @TrackVersions @VersioningControlled ?
>
> 2008/10/25 Elias Ross <genman(a)noderunner.net>:
>> On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
>> <emmanuel(a)hibernate.org> 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 examination of an
>> organization's or individual's accounts or financial situation b: the
>> final report of an audit 2: a methodical examination and review" ..
>> You're not examining anything, really you're remembering.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:58 a.m.
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, its @Id not
@TrackIdentifierValue, etc).
-
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Mon, 2008-10-27 at 10:09 +0100, Max Rydahl Andersen wrote:
> 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,
> > as every programmer
> > has some knowleger of version tracking ( I hope for them at least).
> >
> > @KeepVersions @TrackVersions @VersioningControlled ?
> >
> > 2008/10/25 Elias Ross <genman(a)noderunner.net>:
> >> On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
> >> <emmanuel(a)hibernate.org> 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 examination of
an
> >> organization's or individual's accounts or financial situation b:
the
> >> final report of an audit 2: a methodical examination and review" ..
> >> You're not examining anything, really you're remembering.
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
--
/max
7:44 p.m.
On Oct 24, 2008, at 22:22, Elias Ross wrote:
On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> 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 examination of an
organization's or individual's accounts or financial situation b: the
final report of an audit 2: a methodical examination and review" ..
You're not examining anything, really you're remembering.
You can't audit if you don't have history :)
8:48 a.m.
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
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Fri, 2008-10-24 at 19:22 -0700, Elias Ross wrote:
On Fri, Oct 24, 2008 at 5:00 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> 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 examination of an
organization's or individual's accounts or financial situation b: the
final report of an audit 2: a methodical examination and review" ..
You're not examining anything, really you're remembering.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:19 a.m.
> 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 really think it creates confusion?
Yes - the names are not distinct enough.
/max
9:59 a.m.
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
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Thu, 2008-10-23 at 10:42 +0200, Adam Warski wrote:
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 you really think it creates confusion?
> Some "Version"-free class naming ideas:
>
> RevisionListener
> VersionsReader -> RevisionReader | HistoryReader
The "RevisionXXX" names would suggest that it's for reading revision
data, so revision entities, not the acutal historic data. If at all,
"HistoryXXX" seems much better (HistoryReaderFactory,
SecondaryHistoryTable, HistoryTable, HistoryJoinTable).
If there would be a name change, then the old classes/annotations
should be deprecated, not removed - people wouldn't want to see their
code broken after upgrading to a newer version.
> Unversioned -> Unrevised | Untracked ?
> Versioned -> Revised | Historical
There was also the idea of "Historized" :) Then also: Unhistorized.
> VersionsJoinTable -> RevisionJoinTable | HistoryJoinTable
> VersionsTable -> RevisionTable | HistoryTable
>
> Envers -> Enrise -> Enhist ?
I would keep the current name, people got used to it :) And it doesn't
directly suggest anything with versioning.
Adam
6:48 p.m.
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 15:09, Steve Ebersole wrote:
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
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Tue, 2008-10-21 at 20:41 +0200, Adam Warski wrote:
>> 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 you, I've just released
> Envers 1.1.0.GA. The main new features are the possibility to version
> most types of relations and persistent collections and an improved
> revisions-of-entities query; you can now read the history of an
> entity
> along with revisions metadata in a single query.
>
> More details on the blog: http://www.warski.org/blog/?p=20 and the
> website: http://www.jboss.org/envers/
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:17 a.m.
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 enviroment with Hibernate Annotations/EntityManager. So
I used ReflectionManager to read the @Versioned annotations. In a pure
Hibernate environment, this will not work.
--
Adam
6:07 a.m.
Hi,
On Thu, 23 Oct 2008 12:17:18 +0200, Adam Warski <adam(a)warski.org> 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 ReflectionManager to read the @Versioned annotations. In a pure
Hibernate environment, this will not work.
I don't think that making Envers a module in Core means that you cannot use
Hibernate Annotations/EnityManager. In fact these two projects are about
to be
moved back into Core. As their own (maven) modules of course.
--Hardy
6:19 a.m.
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 Hibernate environment, this will not work.
I don't think that making Envers a module in Core means that you
cannot use
Hibernate Annotations/EnityManager. In fact these two projects are
about to be
moved back into Core. As their own (maven) modules of course.
Ah, ok. Then Envers would have a dependency on the annotations module
(+ users would have to use AnnotationConfiguration instead of
Configuration). Makes sense, as you configure Envers through
annotations (mark classes as versioned/historized), so you probably
also use Annotations/EntityManager then, not "pure" Hibernate.
--
Adam
6:31 a.m.
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 annotations. In a
>> pure Hibernate environment, this will not work.
>
> I don't think that making Envers a module in Core means that you
> cannot use
> Hibernate Annotations/EnityManager. In fact these two projects are
> about to be
> moved back into Core. As their own (maven) modules of course.
Ah, ok. Then Envers would have a dependency on the annotations module (+
users would have to use AnnotationConfiguration instead of
Configuration). Makes sense, as you configure Envers through annotations
(mark classes as versioned/historized), so you probably also use
Annotations/EntityManager then, not "pure" Hibernate.
Personally, I'm still a fan of plain Hibernate non-JPA config. Could the
integration be done with a mind to making it possible to configure
Envers via a standard Configuration in a future release?
Max.
10:05 a.m.
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 completely distinct from pushing EntityManager use
over straight Session use; we are just talking about Annotations instead
of externalized hbm.xml.
Would you be interested in adding this support to the XML/DTD and
HbmBinder + metdata?
-
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Thu, 2008-10-23 at 12:31 +0100, Max Bowsher wrote:
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 annotations. In a
>>> pure Hibernate environment, this will not work.
>>
>> I don't think that making Envers a module in Core means that you
>> cannot use
>> Hibernate Annotations/EnityManager. In fact these two projects are
>> about to be
>> moved back into Core. As their own (maven) modules of course.
>
> Ah, ok. Then Envers would have a dependency on the annotations module (+
> users would have to use AnnotationConfiguration instead of
> Configuration). Makes sense, as you configure Envers through annotations
> (mark classes as versioned/historized), so you probably also use
> Annotations/EntityManager then, not "pure" Hibernate.
Personally, I'm still a fan of plain Hibernate non-JPA config. Could the
integration be done with a mind to making it possible to configure
Envers via a standard Configuration in a future release?
Max.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:01 a.m.
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
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Thu, 2008-10-23 at 12:17 +0200, Adam Warski wrote:
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 enviroment with Hibernate Annotations/EntityManager. So
I used ReflectionManager to read the @Versioned annotations. In a pure
Hibernate environment, this will not work.
9:56 a.m.
This is exactly what we discussed yesterday on IRC.
-
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole(a)jboss.com
steve.ebersole(a)redhat.com
On Wed, 2008-10-22 at 19:48 -0400, Emmanuel Bernard wrote:
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 15:09, Steve Ebersole wrote:
> 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
> steve(a)hibernate.org
>
> Principal Software Engineer
> JBoss, a division of Red Hat
> http://jboss.com
> http://redhat.com
> steve.ebersole(a)jboss.com
> steve.ebersole(a)redhat.com
>
>
> On Tue, 2008-10-21 at 20:41 +0200, Adam Warski wrote:
>>> 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 you, I've just released
>> Envers 1.1.0.GA. The main new features are the possibility to version
>> most types of relations and persistent collections and an improved
>> revisions-of-entities query; you can now read the history of an
>> entity
>> along with revisions metadata in a single query.
>>
>> More details on the blog: http://www.warski.org/blog/?p=20 and the
>> website: http://www.jboss.org/envers/
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
5820
days inactive
5837
days old
32 comments
8 participants
participants (8)
-
Adam Warski -
Elias Ross -
Emmanuel Bernard -
Hardy Ferentschik -
Max Bowsher -
Max Rydahl Andersen -
Sanne Grinovero -
Steve Ebersole