Bug 966559

I assumed that criteria stuff defaults to sort by id if no other sort is given, which is obviously not right.

Actually the code in question already does/did use a sort by name, so should not return the same resource twice.
Perhaps the name is not enough as there are multiple resources with name 'snert' in my inventory and the db is then returning them in random order


17:03:22] <pilhuhn>	         ResourceCriteria criteria = new ResourceCriteria();
[17:03:22] <pilhuhn>	         criteria.addSortName(PageOrdering.ASC);
[17:03:33] <pilhuhn>	 ...
[17:03:34] <pilhuhn>	 PageList<Resource> ret = resMgr.findResourcesByCriteria(caller,criteria);
[17:04:11] <pilhuhn>	 when I run the results with paging over the various pages, I see duplicates like lzoubek  did in Bug 966559
[17:04:14] <rhq-bot>	 BZ 966559 [product=RHQ, priority=unspecified, status=ON_DEV] Paging returns same resource on different pages [ https://bugzilla.redhat.com/966559 ]
[17:04:31] <pilhuhn>	 If I add a criteria.addSortId(PageOrdering.ASC)  the dupe goes away
[17:06:44] <pilhuhn>	 See https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/rest/ResourceHandlerBean.java#n190

[17:17:01] <jshaughn>	 pilhuhn: I think that that is likely the issue
[17:17:21] <jshaughn>	 it's not really something we had considered in the past, but I don't see why that wouldn't be a problem
[17:17:41] <jshaughn>	 the db vendor should not necessarily guarantee any ordering other than name
[17:17:57] <jshaughn>	 and if you have dup names then you could get them ordered in any way
[17:18:05] <jshaughn>	 sort of dumb for us not to really think about that
[17:18:20] <jshaughn>	 I agree sort or name, id for safety
[17:18:34] <jshaughn>	 of course you know what this means...
[17:18:41] <jshaughn>	 a sweep
[17:18:43] <pilhuhn>	 We will get dups "naturally", as all agents are named rhq-agent for example
[17:19:08] <jshaughn>	 +1, paging on a field with dups is not going to be safe, I think
[17:19:42] <jshaughn>	 especially after Lukas's recent changes.
[17:19:51] <pilhuhn>	 For the rest api, it is an easy change for me -- but  I guess CLI clients may run into the same issue. And perhaps even the UI
[17:20:50] <jshaughn>	 we may have been getting lucky, if we were paging on a query with join fetch we would have been actually fetching everything and then getting  consistent ordering wuith the in-mem handling
[17:21:13] <jshaughn>	 absolutely, CLI, GUI, perhaps even SLSB calls
[17:21:22] <jshaughn>	 we need a sweep now...
[17:21:38] <jshaughn>	 looking for our sort specifiers all over the place
[17:21:51] <jshaughn>	 and adding id as a secondary sort if necessary
[17:22:16] <jshaughn>	 either that or we build it into base Criteria handling
[17:22:36] <jshaughn>	 but I'm not sure I like to be that heavy-handed
[17:25:26] <pilhuhn>	 We would perhaps need to make our criteria fields know if they are unique. the Criteria execution could then look them up and if there is a unique one (like id) it would just use that. Otherwise it would automagically add a sortById as fallback
[17:27:23] <pilhuhn>	 biab
[17:28:30] <jshaughn>	 I think perhaps just making a jdoc note on the appropriate addSort methods may be sufficient, and adding another "tip" to the criteria tips and tricks page.
[17:30:42] <jshaughn>	 another possibility is always adding an id sort when paging is specified *unless* there is an override set: addSortId(false)
[17:31:05] <jshaughn>	 that may be smart
[17:57:40] <pilhuhn>	 Yep, that sounds good

This specific issue was pushed to master as 6d5e400

The more generic issue has been opened as Bug 966665 - this one also blocks some rest-api controls for using user-supplied sort fields

verified on Version: 4.8.0-SNAPSHOT Build Number: 0d6dcd4

Bulk close of old bugs in VERIFIED state.