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

* Your Email Address
* Spam protection	Enter the letters below: __ .__..__..___. . / `\| \|\| \|[__ \| \| \__.\|__\|\|__\\| \|/\\|
Comment	> 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.
Attachment
Watch this ticket