[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
efficiency...
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 ...
Dale
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:
>>>
>>>
>>> SELECT OBJECT
>>>
>>> [ 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