The branch "master" has been updated.
The following is a summary of the commits.

from: 146eff9094f090b96fc15123ee87ae2a24f8583a

ab063da More detailed comments, update test.

-----------------------------------------------------------------------

commit ab063da2d93d55184e43cb248a54df5db5a49857
Author: Michael J Rubinsky <mrubinsk at horde.org>
Date:   Thu Aug 22 15:54:01 2013 -0400

     More detailed comments, update test.

  framework/History/lib/Horde/History/Sql.php       |   22 +++++++++++++++++---
  framework/History/test/Horde/History/TestBase.php |   16 ++++++++++----
  2 files changed, 29 insertions(+), 9 deletions(-)

http://git.horde.org/horde-git/-/commit/ab063da2d93d55184e43cb248a54df5db5a49857

It should be documented then, that the values don't have any meaning, 
and the test needs to be fixed accordingly.

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.

That won't work, because columns in the ORDER BY clause need to be in 
the SELECT list too, in pgsql. selectAssoc() won't work with three 
columns though.

If the actual values of the array don't matter, why are they returned 
at all? If the purpose of the method is to just return object IDs, why 
doesn't it simply return object IDs?

The function searches for unique object uids that changed during a 
given modseq range.
So it's not important which row it returns.

If we want to return the most recent row, we could add an "ORDER BY 
modseq DESC" statement, though it's not currently not needed. The user 
can use the getLatestEntry($object_uid) if really needed.

Thanks for checking it in detail though!

Changes have been made in Git (master):

commit a07656fcdbfeefd7781015e49d0c2b1d32ebc9cb
Author: Jan Schneider <jan@horde.org>
Date:   Thu Aug 22 12:53:12 2013 +0200

     Disable test for undefined getByModSeq() behavior (Bug #12600).

  framework/History/test/Horde/History/TestBase.php |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/a07656fcdbfeefd7781015e49d0c2b1d32ebc9cb

While tracking down failed History tests on Postgres, I noticed some 
strange, at least undefined behavior of getMyModSeq(). Is it supposed 
to return all history IDs of changed during the modseq sequence, or 
only the most recent? It does neither, currently. And the docs are 
confusing: "@return array  An array of history object ids"
Returning all entries doesn't work because the returned hash is keyed 
by object IDs, so it will only return at most one entry per object.
Returning the most recent entry doesn't work because the query doesn't 
specify any order, so selectAssoc() will return whatever happens to be 
the last returned row.