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

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

 

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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

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 [hidden email] 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

 

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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 <[hidden email]> 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 [hidden email] 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

 

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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

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 [hidden email] 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 [hidden email] 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

 

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass