Issue 1101: searching by abbreviated change-id returns no result
Status:  New
Owner: ----
Reported by steffen....@googlemail.com, Aug 19, 2011
Affected Version: 2.2.1-67-g17ca55f

What steps will reproduce the problem?
1. Open http://egit.eclipse.org/r/#q,If1431980,n,z

What is the expected output? What do you see instead?

I would expect that review If1431980a68a13fa605d9ec328e044c5646e561c is opened but no results are displayed. 

Searching for the full change-id "If1431980a68a13fa605d9ec328e044c5646e561c" works fine.

Please provide any additional information below.

The documentation states that searching for "Full or abbreviated Change-Id" is supported: http://egit.eclipse.org/r/Documentation/user-search.html


Aug 19, 2011
#1 steffen....@googlemail.com
As mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=350679#c11 this might be dependent on the underlying database:

Matthias Sohn 2011-08-19 09:03:27 EDT
(In reply to comment #8)
...
> Unfortunately Gerrit does not support searching by abbreviated change-id so we
> are not able to support this on the client until that's fixed:
> https://code.google.com/p/gerrit/issues/detail?id=1101

AFAIK this depends on the underlying database platform, I just tried and found
it works on postgres and doesn't work on MySQL
Apr 11, 2012
#2 dbailey%...@gtempaccount.com
Works for mysql depending on the length of the abbreviated change id

See the following test results for a change id of "Id79aa0e4c4ef4c9f27f8111746ed351bff1fcd84" where 'y' = successful return of the change and 'x' unsuccessful search.

y Id79aa0e4c4ef4c9f27f8111746ed351bff1fcd84
y Id79aa0e4c4ef4c9f27f8111746ed351bff1fcd8
y Id79aa0e4c4ef4c9f27f8111746ed351bff1fcd
x Id79aa0e4c4ef4c9f27f8111746ed351bff1fc
x Id79aa0e4c4ef4c9f27f8111746ed351bff1f
x Id79aa0e4c4ef4c9f27f8111746ed351bff1
y Id79aa0e4c4ef4c9f27f8111746ed351bff
x Id79aa0e4c4ef4c9f27f8111746ed351bf
x Id79aa0e4c4ef4c9f27f8111746ed351b
x Id79aa0e4c4ef4c9f27f8111746ed351
y Id79aa0e4c4ef4c9f27f8111746ed35
y Id79aa0e4c4ef4c9f27f8111746ed3
y Id79aa0e4c4ef4c9f27f8111746ed
x Id79aa0e4c4ef4c9f27f8111746e
x Id79aa0e4c4ef4c9f27f8111746
y Id79aa0e4c4ef4c9f27f811174
y Id79aa0e4c4ef4c9f27f81117
y Id79aa0e4c4ef4c9f27f8111
y Id79aa0e4c4ef4c9f27f811
y Id79aa0e4c4ef4c9f27f81
y Id79aa0e4c4ef4c9f27f8
y Id79aa0e4c4ef4c9f27f
x Id79aa0e4c4ef4c9f27
y Id79aa0e4c4ef4c9f2
y Id79aa0e4c4ef4c9f
x Id79aa0e4c4ef4c9
y Id79aa0e4c4ef4c
x Id79aa0e4c4ef4
y Id79aa0e4c4ef
x Id79aa0e4c4e
x Id79aa0e4c4
y Id79aa0e4c
x Id79aa0e4
y Id79aa0e
x Id79aa0
y Id79aa
x Id79a


Apr 11, 2012
#3 dbailey%...@gtempaccount.com
Turns out that the mysql jdbc driver is converting the max character (in gerrit-reviewdb/src/main/java/com/google/gerrit/reviewdb/Change.java) '\u9fa5' to '?' by default in queries due to the default charset being 'latin1'.

Confirmed this by turning on logging in mysql using:
SET GLOBAL log_output = "FILE";
SET GLOBAL general_log_file = "/var/log/mysql/queries.log";
SET GLOBAL general_log = 'ON';

And see the following query:
SELECT T.change_key,T.created_on,T.last_updated_on,T.sort_key,T.owner_account_id,T.dest_project_name,T.dest_branch_name,T.open,T.status,T.nbr_patch_sets,T.current_patch_set_id,T.subject,T.topic,T.last_sha1_merge_tested,T.mergeable,T.row_version,T.change_id FROM changes T WHERE T.change_key>='Id79aa0e4c4ef4c9f27f8111746ed351bff1fc' AND T.change_key<='Id79aa0e4c4ef4c9f27f8111746ed351bff1fc?'

Converting all the database tables to utf8 and specifying the driver using
[database]
    url = jdbc:mysql://localhost/reviewdb?useUnicode=yes&characterEncoding=UTF-8

and then monitoring the queries showed
SELECT T.change_key,T.created_on,T.last_updated_on,T.sort_key,T.owner_account_id,T.dest_project_name,T.dest_branch_name,T.open,T.status,T.nbr_patch_sets,T.current_patch_set_id,T.subject,T.topic,T.last_sha1_merge_tested,T.mergeable,T.row_version,T.change_id FROM changes T WHERE T.change_key>='Id79aa0e4c4ef4c9f27f8111746ed351bff1fc' AND T.change_key<='Id79aa0e4c4ef4c9f27f8111746ed351bff1fc龥'

That '龥' is what the \u9fa5 represents.

So simple solution to having abbreviated change ids work with mysql is to use UTF8 instead of latin1.
Apr 11, 2012
Project Member #4 bklarson@gmail.com
I believe you will run into other problems if using utf8 with mysql.  See  Issue 1273 .
Apr 11, 2012
#5 dbailey%...@gtempaccount.com
I didn't encounter that issue possibly due to use of InnoDB tables instead of MyISAM.