OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cxs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cxs] Update on object-specific query language

Yes of course. We would just have to come up with a JSON schema to express it but that shouldn’t be too difficult.

I forgot to mention that we also talked about using parenthesis to control precedence more finely, but in JSON this would be easier to do by using the tree directly.


On 16 juin 2016, at 17:35, Jan Blessenohl <Jan.Blessenohl@telerik.com> wrote:

Hi guys,
We can additional put that into a json tree to avoid the query parsing, or? The simplicity can be kept from my perspective.
From: cxs@lists.oasis-open.org [mailto:cxs@lists.oasis-open.org] On Behalf Of Thomas Sigdestad
Sent: Donnerstag, 16. Juni 2016 15:49
To: Serge Huber <shuber@jahia.com>
Cc: cxs@lists.oasis-open.org
Subject: Re: [cxs] Update on object-specific query language
This sounds interesting to me, and I believe the "shortversions" are most useful in terms of softening The transition from SQL, but a pure function language would be much easier to implement I guess?
What might we miss out on compared to regular WHERE statements? 
Vennlig hilsen/Best regards 

Thomas Sigdestad
CTO & Co-Founder
+47 98236011

https://enonic.com - A web operating system for your sites and applications

Den 16. jun. 2016 kl. 09.25 skrev Serge Huber <shuber@jahia.com>:

Hello guys, 

Yesterday Chris and I worked on specifying a query language for object-specific queries. We mostly focused on the profile queries, and came up with something relatively simple, although not extremely compact. Basically the syntax looks something like this : 


where function is something like

   equals(propertyName, propertyValue)
   lessThan(propertyName, propertyValue)
   greaterThan(propertyName, propertyValue)
   closeTo(propertyName, geoLocation, distance)

and OPERATOR is one of : 


For example we can express something like : a profile between 30 and 60 and close to geneva with something like this

   greaterThan(‘age’, 30) AND lessThan(‘age’, 60) AND closeTo(‘city’, ‘geneva’, 30000)

Chris mentioned it was a bit verbose but at the same time it is very simple to implement and use. We could imagine then supporting either shorter function names such as : eq, gte (greaterThanOrEqualTo), lte (lessThanOrEqual). We could even see if we wanted to support “shortcuts” so that we can use the <=, >= operators but these would simply get translated into function calls.

The nice thing about functions is that they can be extended by an implementation, meaning that implementations could provide more powerful functions. We could even imagine functions that would query other objects, in effect providing some sort of “application join” functionality. 

We propose that we define a built-in set of core functions in the specification, and that we then leave the door open for extensibility.

Personally I like this proposal because it is a good compromise between simplicity and functionality, but of course we’d love to have your feedback.

To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]