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.getQueryTranslatorFactory(),
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.
