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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> 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. >>>>>> >>>>>> >>>>> >>>>> > -- *Regards,* Wail Alkowaileet
