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.
