[Glass] We have queries ... do we also get sorts and limits, offset ?

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Thu May 26 13:38:33 PDT 2016

I think that it would be very straightforward to provide a NOSQL 
object/api based query model with the additional features you suggest.

SET is already handled by #bind:to:

ORDERBY, LIMIT, OFFSET could be implemented with an 
#orderBy:direction:offset:limit: method  implemented  in GsQuery with 
mostly "off the shelf" methods and classes: a combination of a query  
readStream for offset and limit and a combination of 
Collection>>sortDescending: or Collection>>sortDescending: for direction 
... if performance were an issue, I think it would be possible to 
incorporate the offset and limit into the query evaluator and gain some 

I'm less inclined to implement OSQL style queries because the object/api 
based queries are so much more flexible - allowing UI designers to 
compose query objects from custom ui elements rather than require the 
end-user to compose an OSQL query themselves.

I recognize that for some applications the end users are sophisticated 
enough and familiar enough with the object model to compose their own 
OSQL queries, but I would think that with petit parser it might be 
possible to design a query language that is application specific rather 
than try to come up with a generic query language that meets all needs ...


On 05/26/2016 11:34 AM, Marten Feldtmann wrote:
> Well, there are several use cases here:
>   * better support for typical paged-size application
>   * our user can indeed type in base sql syntax: "select * from table
>     where attribut = value" - for starters you may put typical
>     klick-and-click interface before that step.
>   * the string based syntax seems to be much secure than tradition
>     block-based stuff and one of the biggest problems in the Smalltalk
>     area I've seen over years is the missing of scripting support and
>     query support and all guys develop their own sandbox system just
>     to solve problems again and again and again.
>   * and yes - Gemstone is a database for me and this means, that
>     retrieving values, sorting, grouping is a very important point for me.
>   * and the idea with select (attribute, attribute) becomes more
>     brilliant the more I think about ...
> Its a boring situation to tell customers, that oo-dbms systems have 
> limited query facilities in comparision to their so well known 
> relational database.
> Marten
>> Dale Henrichs <dale.henrichs at gemtalksystems.com> hat am 26. Mai 2016 
>> um 15:59 geschrieben:
>> Marten,
>> So you are proposing extensions to the query language? ... Do you 
>> expect your end users to be writing these queries?
>> There is a Smalltalk API for creating queries where you can define 
>> predicates programmatically. When you do this you have a lot more 
>> freedom in creating queries. For example, I've added a block 
>> predicate where you can include a Smalltalk block as part of GsQuery 
>> expression --- I haven't defined a query syntax for including a 
>> smalltalk block, but the programmatically it is very useful in some 
>> cases ...
>> Dale
>> On 5/26/16 3:48 AM, Marten Feldtmann wrote:
>>> Ok,
>>> first I'm not talking about how to use avalable indices or stuff 
>>> like this - and perhaps OQL (ODMG 3.0) is a little bit overkill.
>>> I would like to see something like:
>>> [ SET  variable = value, .... ]
>>> WHERE <old GsQuery string >
>>> ORDERBY <path> <asc | desc>
>>> LIMIT <number>
>>> OFFSET <number>
>>> Some points:
>>>   * GsQuery should work on UnOrderedCollection and OrderedCollections
>>>   * If ORDERBY is missing, the order of the original data collection
>>>     should be used
>>>   * All values defined in the SET part may be used in the original
>>>     GsQuery statement (e.g. to make special values available like
>>>     "Date today")
>>>   * LIMIT limits the number of returned items
>>>   * OFFSET starts returning items at index <number>
>>>   * SELECT OBJECT means, that the "each" object is returned,
>>>     otherwise this can be enhanced e.g. (select each.id as 'id', 
>>>     each.address.id as 'addressid') and it returns Collections of
>>>     dictionaries (direct feedable to JSON)
>>>   * ORDERBY - this can be enhanced by  several sort specification
>>>     (but one is ok for now)
>>>   * reuse of queries would be nice, but difficult ?
>>> Marten
>>>> Dale Henrichs via Glass <glass at lists.gemtalksystems.com> 
>>>> <mailto:glass at lists.gemtalksystems.com> hat am 24. Mai 2016 um 
>>>> 19:24 geschrieben:
>>>> Marten,
>>>> I think your direction makes a lot of sense :)
>>>> Could you put together a more detailed proposal in the form of 
>>>> suggested method selectors and descriptions. I could then use that 
>>>> as an implementation spec ... perhaps others will have additional 
>>>> suggestions as well and I could kill several birds with one stone ...
>>>> Dale
>>>> On 05/24/2016 01:27 AM, Marten Feldtmann via Glass wrote:
>>>>> We have already GsQuery (for filtering) - can we get also stuff 
>>>>> (or extensions of GsQuery) like:
>>>>>   * sort by attribute and direction of sorting: ascending, descending
>>>>>   * from the result copy a fraction of data: offset and limit
>>>>> ... you see my direction :-)
>>>>> Marten
>>>>> _______________________________________________
>>>>> Glass mailing list
>>>>> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160526/57c11e4c/attachment-0001.html>

More information about the Glass mailing list