Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Solving a Problem in a Way That Doesn’t Generate Dozens More

DZone's Guide to

Solving a Problem in a Way That Doesn’t Generate Dozens More

In this post, we take a look at an example of how to approach solving a particular query problem without introducing several more. Read on for the goods.

· Performance Zone
Free Resource

Yesterday, I showed off some of the new features in RQL, and in particular, two very cool features, the ability to declare functions and the ability to project an object literal directly from the select.

Both of these features are shown here, including usage demonstration:

image

Take a minute to read the query, then consider what we are doing here.

One of the things we want to enable is to have powerful query capabilities. We started with what SQL syntax and very quickly hit the wall. Leaving aside the issue of working with just the rectangular format of SQL, there is a huge problem here.

Something like N1QL or the Noise syntax have both seems that you can deal with non-rectangular formats with enough effort. But the problem is that there is really no really good way to express complex imperative stuff easily. For example, N1QL has about 30 functions just to deal with arrays, and 40 just for dates. And those are just the first I looked up that were easy to count.

Going with something with a SQL syntax, including subqueries, complex nesting of expressions, etc would have led to a really complex language. Both from the point of view of implementation and from the point of view of the users.

On the other hand, with RQL, you get the familiar query language, and if you want to just get some data to display, you can do that. When you need to do more, you move to using the object literal syntax and if you need to apply more logic, you write a small function for that and call it.

Imagine writing the code above in SQL (just the fact that the Nicks array is on a separate table means that you’ll have a correlated subquery there), and this is a pretty simple query. Choosing this approach means that we actually have very little expected support burden.

That is important because with the other option I could absolutely see a lot of requests for “can you add a function to do X”, “how do I add my own function” popping up all the time in the support channels. This way, we give it all to you already and the solution is self-contained and extensible as needed very easily.

Topics:
syntax ,performance ,sql ,queries

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}