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.

cheers,

  Serge… 

On 16 juin 2016, at 17:35, Jan Blessenohl <> 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.

 

Jan

 

From:  [mailto:] On Behalf Of Thomas SigdestadSent: Donnerstag, 16. Juni 2016 15:49To: Serge Huber <>Cc: : 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? 

 

How 

 

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 <>:

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 :    [OPERATOR] FUNCTION OPERATOR FUNCTIONwhere function is something like   equals(propertyName, propertyValue)   lessThan(propertyName, propertyValue)   greaterThan(propertyName, propertyValue)   closeTo(propertyName, geoLocation, distance)and OPERATOR is one of :    AND   OR   NOTFor 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.cheers, Serge… ---------------------------------------------------------------------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:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php