Revisions numbers are unlogical

[bobvandevijver]

Every object should start with rev 1, the insert statement.
The next update should give rev 2, not rev 26 if there were 24 other changes to other, unrelated objects of the same type happened inbetween.

[felipepastor]

Yeap, i'm using EntityAudit with zf1 and the configuration looks great, after insert or update the objects are saved in both original and audit table, but how @bobvandevijver says, because of the auto increment in table revisions, the audit table is getting wrong value in rev field. All the news items need to receive 1 as "rev".

Before i start to change some codes i would like to know if there's any solution for this. Any tips?

Thanks for the lib.

[andrewtch]

Can you give a test case to repeat that? The thing is that I'm working on major core modifications, so we can mess each other's work )

[bobvandevijver]

@felipepastor Maybe is my repository (https://github.com/bobvandevijver/EntityHistoryBundle) something for you: If have adjusted this repo and changed these kind of things especially to solve these things.
However, I've also removed a few features which I do not need. Be advised, I do not have written any updated docu, but it works perfectly in my case.

[tolry]

If I understand your report correctly, this is the intended behavior and emulates what Hibernate Envers does. EntityAudit assigns global revisions as e.g. subversion does, in contrast to assigning revisions to every object/table separately as e.g. CVS does.

Both strategies have their downsides an merits, but changing this behavior in EntityAudit would be a huge BC problem. As I am no real expert on all of this, I might be right, but EntitzAudit's approach has advantages when doing point-in-time rollbacks/recoveries.

[bobvandevijver]

To comment on @tolry, point-in-time reverts are still possible if you use a timestamp when saving the history. This is something I do, but which is mainly caused by the Blamable behaviour I've implemented.

[andrewtch]

Ah, I got the idea. This is strongly not a desirable behavior - doctrine uses UnitOfWork, that represents ALL managed entities. So, one flash = one revision and I'm quite against that ( @DavidBadura , what do you think?).

Au contraire, I'm planning to implement metadatas ( #37 ) that will allow you to tag any meta to a revision and query them later. Therefore, you'll be able to create your own tagging / numbering strategy.

[felipepastor]

All right, i've missed some point of this discussion, anyway, before test the repo created by @bobvandevijver here what is going on...

1. I'm using ZF1 + Doctrine2 + SQL SERVER :( so i created the tables revisions (with "timestamp" datetime, "username" varchar and id int auto-increment) and *_audit (with "rev" int and "revtype" varchar(3) columns)

2. Then, i've set some EntityAudit configuration before i save or update an object. Its saving and updating in both tables like a charm. See pictures below:

original table

_audit table

revisions table

3. If you take a look in _audit table the rev column is getting the pk of revision globally.

That's it, now, i'll take a look in the @bobvandevijver 's repo to find something i can use in my project, thanks again for attention.

[felipepastor]

Hi again,

After studying and knowing my app better, its possible to use this lib without any changes, i was mirroring it with a plugin called DmVersionable for SF1 + DIEM, i don't know if you guys already developed something in these tools. Anyway only for explanation, it doesn't have a revision global table and the audit table has a rev column but not auto incremented it is always 1 for new objects and then updated for 2, 3... if has any changes. That's it, I think i'll update the documentation, describing my difficult and how to solve as well some examples for stand-alone implementation.
If you have curiosity of diem, the link is: http://diem-project.org/

Thanks.

[DavidBadura]

I am the opinion of @andrewtch. We should try to implement #37