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 Sun, 05 Feb 2017 17:40:33 GMT
Interesting!  (It would be cool, obviously, if there were some 
engineered/low-cost way to always have both...) Sounds like the Hive vs. 
Pig split in Hadoop/MR-land.

On 2/5/17 9:38 AM, Wail Alkowaileet wrote:
> According to my *biased* sample, I noticed people with Computer Science
> background prefer SQL++ more than AQL. Simply because they're trained to
> write SQL queries.
> However, when I show AsterixDB to Computational Physics/Engineering/Data
> Science folks whom they are used to Matlab and Python, they seems to like
> AQL more. They say "it looks like writing a Python code". I think it
> depends on how people are trained to do stuff.
> On Sat, Feb 4, 2017 at 11:49 AM, Mike Carey <> wrote:
>> 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 trivially.)
>> 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.)
>> Cheers,
>> Mike
>> 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.getQueryTr
>>>>> anslatorFactory(),
>>>>> 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
>>>>>> 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
>>>>>> to
>>>>>> implement a new generator.
>>>>>> On Feb 3, 2017, at 6:02 PM, Yingyi Bu <>
>>>>>>> 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