[Tickets #13868] Re: Changes made in kronolith are not send to AS devices.

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/13868
------------------------------------------------------------------------------
  Ticket             | 13868
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Changes made in kronolith are not send to AS devices.
  Queue              | Synchronization
  Version            | FRAMEWORK_5_2
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2015-02-26 15:29) wrote:

> I was looking in the database table "horde_histories".
> So every change in contacts, calender and tasks are logged in  
> "horde_histories" right?

Correct. Each change *should* get a higher value.

> - I was wondering if "history_modseq" should allways increased or  
> can it reset? And when will it reset?

It should never reset. If it does, there is an issue somewhere in the  
database layer.

> See upper picture of the table where history_id gets async with  
> history_modseq.

It's possible that an existing history entry is modified, rather than  
replaced in certain cases, but this still looks funky, especially  
given the range of values.

> - high "history_modseq" is related to the lasted modification? See  
> lower picture of the table where history_ts is sorted min to max.  
> Where I can see that the highest history_ts is not allways the  
> lasted history_id. Is this correct?

Probably not, and this can most definitely mess things up.

> Can I empty horde_histories to start over without any consequence?

That would probably be the best bet at this point, though you may lose  
data related to editing objects - such as who last modified a contact,  
for example. If that data is important for you to maintain,  you can  
use the horde-db-migrate script to migrate the history library down to  
the "2" migration and then back "up". This should reset the modseq  
values for you.

Still, would be nice to figure out WHY the modseq value was reset.   
Maybe it IS related to the other bug, though I thought that was only  
pgsql...