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 <[email protected]> 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 <[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. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >> >
