Based on a user request. For some searches, ordering by id descending (approximately "most recent") makes more sense. --- www/kojiweb/index.py | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/www/kojiweb/index.py b/www/kojiweb/index.py index 876d956..433d943 100644 --- a/www/kojiweb/index.py +++ b/www/kojiweb/index.py @@ -2178,8 +2178,20 @@ _infoURLs = {'package': 'packageinfo?packageID=%(id)i', _VALID_SEARCH_CHARS = r"""a-zA-Z0-9""" _VALID_SEARCH_SYMS = r""" @.,_/()%+-*?|[]^$""" _VALID_SEARCH_RE = re.compile('^[' + _VALID_SEARCH_CHARS + re.escape(_VALID_SEARCH_SYMS) + ']+$') - -def search(environ, start=None, order='name'): +_DEFAULT_SEARCH_ORDER = { + # For searches against large tables, use '-id' to show most recent first + 'build' : '-id', + 'rpm' : '-id', + 'maven' : '-id', + 'win' : '-id', + # for other tables, ordering by name makes much more sense + 'tag' : 'name', + 'target' : 'name', + 'package' : 'name', + # any type not listed will default to 'name' +} + +def search(environ, start=None, order=None): values = _initValues(environ, 'Search', 'search') server = _getServer(environ) values['error'] = None @@ -2211,6 +2223,7 @@ def search(environ, start=None, order='name'): if not infoURL: raise koji.GenericError, 'unknown search type: %s' % type values['infoURL'] = infoURL + order = order or _DEFAULT_SEARCH_ORDER.get(type, 'name') values['order'] = order
results = kojiweb.util.paginateMethod(server, values, 'search', args=(terms, type, match),
On 12/14/2015 11:20 AM, Mike McLean wrote:
Based on a user request. For some searches, ordering by id descending (approximately "most recent") makes more sense.
I've very interested in what people think about this potential behavior change. It mostly seems right to me, though I don't think any simple default can be 100% correct.
The thinking here is that we should default to order=-id for tables where folks are probably interested in the most recent results.
Of course, name order is always just a header click away.
www/kojiweb/index.py | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/www/kojiweb/index.py b/www/kojiweb/index.py index 876d956..433d943 100644 --- a/www/kojiweb/index.py +++ b/www/kojiweb/index.py @@ -2178,8 +2178,20 @@ _infoURLs = {'package': 'packageinfo?packageID=%(id)i', _VALID_SEARCH_CHARS = r"""a-zA-Z0-9""" _VALID_SEARCH_SYMS = r""" @.,_/()%+-*?|[]^$""" _VALID_SEARCH_RE = re.compile('^[' + _VALID_SEARCH_CHARS + re.escape(_VALID_SEARCH_SYMS) + ']+$')
-def search(environ, start=None, order='name'): +_DEFAULT_SEARCH_ORDER = {
- # For searches against large tables, use '-id' to show most recent first
- 'build' : '-id',
- 'rpm' : '-id',
- 'maven' : '-id',
- 'win' : '-id',
- # for other tables, ordering by name makes much more sense
- 'tag' : 'name',
- 'target' : 'name',
- 'package' : 'name',
- # any type not listed will default to 'name'
+}
+def search(environ, start=None, order=None): values = _initValues(environ, 'Search', 'search') server = _getServer(environ) values['error'] = None @@ -2211,6 +2223,7 @@ def search(environ, start=None, order='name'): if not infoURL: raise koji.GenericError, 'unknown search type: %s' % type values['infoURL'] = infoURL
order = order or _DEFAULT_SEARCH_ORDER.get(type, 'name') values['order'] = order results = kojiweb.util.paginateMethod(server, values, 'search', args=(terms, type, match),
On 12/14/15 8:30 AM, Mike McLean wrote:
On 12/14/2015 11:20 AM, Mike McLean wrote:
Based on a user request. For some searches, ordering by id descending (approximately "most recent") makes more sense.
I've very interested in what people think about this potential behavior change. It mostly seems right to me, though I don't think any simple default can be 100% correct.
The thinking here is that we should default to order=-id for tables where folks are probably interested in the most recent results.
This makes sense to me, and sounds like an improvement to the current behavior.
While we're touching search, maybe we should make the default (glob) search default to substring matching, instead of exact matching as it does now. Users can always select exact match searches from the "Search" page.
Of course, name order is always just a header click away.
www/kojiweb/index.py | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/www/kojiweb/index.py b/www/kojiweb/index.py index 876d956..433d943 100644 --- a/www/kojiweb/index.py +++ b/www/kojiweb/index.py @@ -2178,8 +2178,20 @@ _infoURLs = {'package': 'packageinfo?packageID=%(id)i', _VALID_SEARCH_CHARS = r"""a-zA-Z0-9""" _VALID_SEARCH_SYMS = r""" @.,_/()%+-*?|[]^$""" _VALID_SEARCH_RE = re.compile('^[' + _VALID_SEARCH_CHARS + re.escape(_VALID_SEARCH_SYMS) + ']+$')
-def search(environ, start=None, order='name'): +_DEFAULT_SEARCH_ORDER = {
- # For searches against large tables, use '-id' to show most recent first
- 'build' : '-id',
- 'rpm' : '-id',
- 'maven' : '-id',
- 'win' : '-id',
- # for other tables, ordering by name makes much more sense
- 'tag' : 'name',
- 'target' : 'name',
- 'package' : 'name',
- # any type not listed will default to 'name'
+}
+def search(environ, start=None, order=None): values = _initValues(environ, 'Search', 'search') server = _getServer(environ) values['error'] = None @@ -2211,6 +2223,7 @@ def search(environ, start=None, order='name'): if not infoURL: raise koji.GenericError, 'unknown search type: %s' % type values['infoURL'] = infoURL
order = order or _DEFAULT_SEARCH_ORDER.get(type, 'name') values['order'] = order results = kojiweb.util.paginateMethod(server, values, 'search', args=(terms, type, match),
koji-devel mailing list koji-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/koji-devel@lists.fedorahosted.org
On 12/14/2015 02:04 PM, Mike Bonnet wrote:
On 12/14/15 8:30 AM, Mike McLean wrote:
On 12/14/2015 11:20 AM, Mike McLean wrote:
Based on a user request. For some searches, ordering by id descending (approximately "most recent") makes more sense.
I've very interested in what people think about this potential behavior change. It mostly seems right to me, though I don't think any simple default can be 100% correct.
The thinking here is that we should default to order=-id for tables where folks are probably interested in the most recent results.
This makes sense to me, and sounds like an improvement to the current behavior.
While we're touching search, maybe we should make the default (glob) search default to substring matching, instead of exact matching as it does now. Users can always select exact match searches from the "Search" page.
Also sounds reasonable. There is an old rfe for that https://fedorahosted.org/koji/ticket/243
Of course, name order is always just a header click away.
www/kojiweb/index.py | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/www/kojiweb/index.py b/www/kojiweb/index.py index 876d956..433d943 100644 --- a/www/kojiweb/index.py +++ b/www/kojiweb/index.py @@ -2178,8 +2178,20 @@ _infoURLs = {'package': 'packageinfo?packageID=%(id)i', _VALID_SEARCH_CHARS = r"""a-zA-Z0-9""" _VALID_SEARCH_SYMS = r""" @.,_/()%+-*?|[]^$""" _VALID_SEARCH_RE = re.compile('^[' + _VALID_SEARCH_CHARS + re.escape(_VALID_SEARCH_SYMS) + ']+$')
-def search(environ, start=None, order='name'): +_DEFAULT_SEARCH_ORDER = {
- # For searches against large tables, use '-id' to show most
recent first
- 'build' : '-id',
- 'rpm' : '-id',
- 'maven' : '-id',
- 'win' : '-id',
- # for other tables, ordering by name makes much more sense
- 'tag' : 'name',
- 'target' : 'name',
- 'package' : 'name',
- # any type not listed will default to 'name'
+}
+def search(environ, start=None, order=None): values = _initValues(environ, 'Search', 'search') server = _getServer(environ) values['error'] = None @@ -2211,6 +2223,7 @@ def search(environ, start=None, order='name'): if not infoURL: raise koji.GenericError, 'unknown search type: %s' % type values['infoURL'] = infoURL
order = order or _DEFAULT_SEARCH_ORDER.get(type, 'name') values['order'] = order results = kojiweb.util.paginateMethod(server, values,'search', args=(terms, type, match),
koji-devel mailing list koji-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/koji-devel@lists.fedorahosted.org
koji-devel mailing list koji-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/koji-devel@lists.fedorahosted.org
koji-devel@lists.stg.fedorahosted.org
-
Mike Bonnet -
Mike McLean