asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chen Li <che...@gmail.com>
Subject Re: Choosing defaults for AsterixDB
Date Mon, 06 Feb 2017 06:48:10 GMT
Agreed on the future goal of deprecating AQL.  For the code in Cloudberry
to do the translation, we need to have a discussion with Jianfeng about how
to do the migration.

Chen

On Sun, Feb 5, 2017 at 9:40 AM, Mike Carey <dtabass@gmail.com> wrote:

> 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 <dtabass@gmail.com> 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 <tillw@apache.org> 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 <jianfeng.jia@gmail.com>
>>>>>> 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 <buyingyi@gmail.com>
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.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>
>

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