[Tickets #12600] Re: Horde_History::getByModSeq() broken by design?

[noreply at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/12600
------------------------------------------------------------------------------
  Ticket             | 12600
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Horde_History::getByModSeq() broken by design?
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-08-22 15:02) wrote:

The only thing we need to know is that a specific UID has a change  
that matches the filters. It's not important if it has multiple  
changes that match the filters, just that the id changed.

You are correct in that the history_id is not needed in the way the  
method is currently used by ActiveSync (the preg_replace call in the  
various application's listBy() API only ever returns the object uids).

The not-so-technical reason the history_id is also returned is that  
Horde_History_Sql::_getByModSeq() method was pretty much a copy/paste  
of the logic in Horde_History_Sql::_getByTimestamp() method - which  
already existed and behaves in an identical fashion, albeit with  
timestamps instead of modSeq values.

The existing getByTimestamp method couldn't be changed at the time I  
wrote the modSeq stuff because it would break BC with the  
{application}_Api::getChanges() calls which expect the uid in the  
keys. I kept the modSeq version of the logic the same for consistency.