The leading _ does indicate that the method is intended for GS internal
use only ... we do not guarantee that _ methods will be present in
future versions of the product ... with that said, I don't think there
are any plans to remove the selector in the future, but I can't make any
Sending #indexSpec to an UnorderedCollection will return an empty index
spec if there are no indexes on the collection. So `coll indexSpec specs
isEmpty` is probably the best route for the long term. And one could
argue that we should implement isEmpty in GsIndexSpec ... One could also
argue that we should implement a public hasIndexes.
To help with these arguments, what is your use case for needing _hasIndexes?
On 6/5/20 12:36 PM, bruno buzzi brassesco via Glass wrote:
Ok, then i will use your recommendation (i know _xxx is for internal
usage) but i did not search too much to find #indexSpec message.
A Java Web App display Forms with paging behavior (forms are stored in
GS) it call a REST GS Service with the page size and the page number
(the entire collection to display must be sorted by #modifiedTime inst
If the collection is small asSortedCollection can be used without
problems. But if the collection is too big asSortedCollection is out of
The collection with forms can have or not an index by #modifiedTime, if
it has an index then i want to use it with aGsQuery readStream or
The at some point something like this is done:
ifTrue: [self fetchIndexedFormsInstancesOn: instances from:
startIndex to: endIndex] "use aGsQuery readStream"
ifFalse: [self fetchUnIndexedFormsInstancesOn: instances from:
startIndex to: endIndex] "use asSortedCollection"