asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wail Alkowaileet <>
Subject Re: Choosing defaults for AsterixDB
Date Sun, 05 Feb 2017 17:38:19 GMT
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 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
>>>>> to
>>>>> 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
>>>>>> SQL++
>>>>> language design and implementation misses some key pieces.


Wail Alkowaileet

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