asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: Choosing defaults for AsterixDB
Date Sat, 04 Feb 2017 19:49:30 GMT
My $0.01:

- I think users in general will like SQL++ better than AQL for sure.  
This is based on having given lots of talks on AsterixDB and never 
feeling like the audience has been sold on AQL's not being SQL-based.  
Now that Yannis P. has provided a nice SQL-oriented extension that has 
the power of AQL, and especially since Don Chamberlin (originator of SQL 
and major XQuery contributor) is putting brain power into SQL++, I think 
we should surely move over time (and preferably not a lot of time).

- There is a style of SQL++ queries that is very much like AQL - namely, 
where you use SELECT VALUE and use explicit record constructors - that 
should prove surprisingly easy to migrate to.  Thus, I don't think 
migrating our query generator will be as bad as one might think.  (I am 
hopeful that there will be mostly localized 1:1 substitutions in the 
generator's template query components.)  I would estimate a person week 
or less to make the move (for someone who knows the generator) - maybe 
2-3 days to do the work and 1-2 days to exercise it thoroughly in terms 
of tests.  I could assess this better (and would be happy to) if someone 
wants to spend an hour projecting the source code for the generator on 
my office screen and chatting about the differences.  (Maybe in March 
between quarters?)

- It would be nice for new work on projects like BAD to be 
"future-based" rather than "past-based" - e.g., ideally, when there is 
AsterixDB syntax for window functions someday, it would be nice for 
those to be extending SQL++ rather than AQL.  I suspect we could get 
invaluable free language consulting from Yannis P. and maybe even Don 
Chamberlin on our extensions if SQL++ was their basis.  (I think that 
most of the rest of BAD is pretty language-agnostic, so I would estimate 
a day or so to migrate most/all of what's there.  Channels are 
function-bodied and functions are in both languages; there's probably 
very little DML code in the broker, and what's there will migrate 

Anyway, I agree with Chen that we should continue to support AQL for 
awhile - but I also think we should deprecate it, i.e., make it clear 
that it's not the future, so that extension work doesn't start from the 
"wrong" starting point. Note that the reason for wanting to deprecate it 
is that, while it's fun to say we are bi-lingual, and to point to that 
as a benefit of our nicely structured Asterix software stack, it is 
pretty expensive in person time to maintain two of everything - so we 
could get more functionality for our person-buck if we were to focus on 
one thing going forward.  (Otherwise we always need to be trying 
everything in two places, run everything on two languages - doubling the 
cost of running regression tests! - etc.)

Summary:  I would personally like to see us plan, as a community, to 
indeed make a shift.  What I found when I wrote the 101 for SQL++ was 
that it was nice - more concise than AQL - and also more intuitive for 
the most part.  (And that it's also not necessarily as different, when 
used in the way I mentioned above, as you'd think.)



PS - It's tempting to do a 300-person user study at the end of CS122a in 
early March - they're all going to use AsterixDB in the last 1-2 weeks 
of my class - i.e., it'd be interesting to see what happens if half used 
AQL and half used SQL++.  (But I'm not sure how we'd assess the 
results.)  :-)

On 2/3/17 7:28 PM, Chen Li wrote:
> This issue came out during our weekly Cloudberry meeting today.
> We need to be careful about this transition from AQL to SQL++. Considering
> the amount of effort put into the logic of AQL translation in Cloudberry,
> it will be good to keep supporting AQL for a while.  Meanwhile, @Jianfeng,
> we should start thinking about migrating the translation to SQL++.
> On Fri, Feb 3, 2017 at 7:21 PM, Till Westmann <> wrote:
>> It currently doesn’t, but it also requires some more work.
>> If we want to use it for AQL, we should simply be able to create a second
>> instance of it with the AQL compilation provider.
>> Cheers,
>> Till
>> On 3 Feb 2017, at 18:57, Taewoo Kim wrote:
>> Regarding this, I have a question.
>>> Does the new revised HTTP API - Query Service (/query/service) support
>>> AQL?
>>> I am asking this since inside the code, it gets the SQLPP compilation
>>> provider.
>>> public class CCApplicationEntryPoint implements ICCApplicationEntryPoint {
>>>      protected IServlet createServLet(HttpServer server, Lets key,
>>> String...
>>> paths) {
>>>          switch (key) {
>>>              case QUERY_SERVICE:
>>>                  return new QueryServiceServlet(server.ctx(), paths,
>>> ccExtensionManager.getSqlppCompilationProvider(),
>>>                          ccExtensionManager.getQueryTranslatorFactory(),
>>> componentProvider);
>>> Best,
>>> Taewoo
>>> On Fri, Feb 3, 2017 at 6:34 PM, Jianfeng Jia <>
>>> wrote:
>>> @Yingyi, I’m not saying learning SQL++ is difficult.
>>>> Currently, we have a class called AQLGenerator that can translate the
>>>> Cloudberry request syntax to AQL.  It took us several weeks finishing it.
>>>> I guess it will take similar time to write a SQLPPGenerator to achieve
>>>> the
>>>> same goal.
>>>> As long as the RESTFul API can accept AQL, we don’t need to spend time
>>>> implement a new generator.
>>>> On Feb 3, 2017, at 6:02 PM, Yingyi Bu <> wrote:
>>>>> It will be a hard work to switch to SQL++.
>>>>>> Why translating to SQL++ is harder than AQL?  I wonder if the current
>>>> SQL++
>>>>> language design and implementation misses some key pieces.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message