You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Till Westmann <ti...@apache.org> on 2017/01/10 06:46:32 UTC
Choosing defaults for AsterixDB
Hi,
as you know AsterixDB supports 2 query languages (AQL and SQL++) and many
output formats (ADM, clean JSON, lossless JSON, CSV). Our current defaults
for these options (at least on the web interface) are AQL and ADM.
I\u2019d like to propose to change those defaults to be SQL++ and (clean) JSON.
The reason for wanting them to change, is that I think that these choices
are more attractive to new users of the system and thus can help to increase
the adoption of AsterixDB. A user with some database experience is much more
likely to have previous SQL experience and to feel at home with SQL++ than
having XQuery experience and feeling at home with AQL. Similarly, most users
will want to use the data that they get out of AsterixDB in an application
and it will be a lot easier to consume JSON than it is to consume ADM.
I've prepared a (tiny) change to change the defaults [1] and I'm wondering
if there are concerns that should keep us from making this change.
Cheers,
Till
[1] https://asterix-gerrit.ics.uci.edu/#/c/1409/
Re: Choosing defaults for AsterixDB
Posted by Steven Jacobs <sj...@ucr.edu>.
+100
Steven
On Fri, Feb 3, 2017 at 5:37 PM, Jianfeng Jia <ji...@gmail.com> wrote:
> Hi, I want to pick up this thread to verify if the AQL will still be
> supported in the future?
> Currently, Cloudberry automatically translates the JSON request to AQL
> statements. It will be a hard work to switch to SQL++.
>
> I’m not object to set the default option to SQL++. However, we will keep
> the support for AQL, right? (especially in the RESTFull API).
>
> > On Jan 10, 2017, at 5:47 PM, Till Westmann <ti...@apache.org> wrote:
> >
> > Ok, since there’s a lot of agreement and no concerns, I’ll go ahead.
> >
> > Thanks,
> > Till
> >
> > On 10 Jan 2017, at 9:22, Yingyi Bu wrote:
> >
> >> +100!
> >>
> >> On Tue, Jan 10, 2017 at 9:17 AM, Mike Carey <dt...@gmail.com> wrote:
> >>
> >>> +1 from me too for SQL++ and clean JSON.
> >>>
> >>>
> >>>
> >>> On 1/10/17 8:25 AM, Murtadha Hubail wrote:
> >>>
> >>>> +1 to SQL++ and clean JSON.
> >>>>
> >>>> Cheers,
> >>>> Murtadha
> >>>>
> >>>> On Jan 10, 2017, at 9:46 AM, Till Westmann <ti...@apache.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> as you know AsterixDB supports 2 query languages (AQL and SQL++) and
> many
> >>>>> output formats (ADM, clean JSON, lossless JSON, CSV). Our current
> >>>>> defaults
> >>>>> for these options (at least on the web interface) are AQL and ADM.
> >>>>>
> >>>>> I’d like to propose to change those defaults to be SQL++ and (clean)
> >>>>> JSON.
> >>>>> The reason for wanting them to change, is that I think that these
> choices
> >>>>> are more attractive to new users of the system and thus can help to
> >>>>> increase
> >>>>> the adoption of AsterixDB. A user with some database experience is
> much
> >>>>> more
> >>>>> likely to have previous SQL experience and to feel at home with SQL++
> >>>>> than
> >>>>> having XQuery experience and feeling at home with AQL. Similarly,
> most
> >>>>> users
> >>>>> will want to use the data that they get out of AsterixDB in an
> >>>>> application
> >>>>> and it will be a lot easier to consume JSON than it is to consume
> ADM.
> >>>>>
> >>>>> I've prepared a (tiny) change to change the defaults [1] and I'm
> >>>>> wondering
> >>>>> if there are concerns that should keep us from making this change.
> >>>>>
> >>>>> Cheers,
> >>>>> Till
> >>>>>
> >>>>> [1] https://asterix-gerrit.ics.uci.edu/#/c/1409/
> >>>>>
> >>>>
> >>>
>
>
Re: Choosing defaults for AsterixDB
Posted by Taewoo Kim <wa...@gmail.com>.
@Till: Got it. Thanks!
Best,
Taewoo
On Fri, Feb 3, 2017 at 7:21 PM, Till Westmann <ti...@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.getQueryTranslatorFactory(),
>> componentProvider);
>>
>> Best,
>> Taewoo
>>
>> On Fri, Feb 3, 2017 at 6:34 PM, Jianfeng Jia <ji...@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 <bu...@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.
>>>>
>>>
>>>
>>>
Re: Choosing defaults for AsterixDB
Posted by Chen Li <ch...@gmail.com>.
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 <dt...@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 <dt...@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 <ti...@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 <ji...@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 <bu...@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.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>
>
Re: Choosing defaults for AsterixDB
Posted by Mike Carey <dt...@gmail.com>.
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 <dt...@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 <ti...@apache.org> wrote:
>>>
>>> It currently doesn\u2019t, 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 <ji...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> @Yingyi, I\u2019m 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\u2019t need to spend time
>>>>>> to
>>>>>> implement a new generator.
>>>>>>
>>>>>> On Feb 3, 2017, at 6:02 PM, Yingyi Bu <bu...@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.
>>>>>>>
>>>>>>
>
Re: Choosing defaults for AsterixDB
Posted by Wail Alkowaileet <wa...@gmail.com>.
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 <dt...@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 <ti...@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 <ji...@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 <bu...@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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>
--
*Regards,*
Wail Alkowaileet
Re: Choosing defaults for AsterixDB
Posted by Mike Carey <dt...@gmail.com>.
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 <ti...@apache.org> wrote:
>
>> It currently doesn\u2019t, 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 <ji...@gmail.com>
>>> wrote:
>>>
>>> @Yingyi, I\u2019m 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\u2019t need to spend time to
>>>> implement a new generator.
>>>>
>>>> On Feb 3, 2017, at 6:02 PM, Yingyi Bu <bu...@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.
>>>>>
>>>>
>>>>
Re: Choosing defaults for AsterixDB
Posted by Chen Li <ch...@gmail.com>.
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 <ti...@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.getQueryTranslatorFactory(),
>> componentProvider);
>>
>> Best,
>> Taewoo
>>
>> On Fri, Feb 3, 2017 at 6:34 PM, Jianfeng Jia <ji...@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 <bu...@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.
>>>>
>>>
>>>
>>>
Re: Choosing defaults for AsterixDB
Posted by Till Westmann <ti...@apache.org>.
It currently doesn\u2019t, 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 <ji...@gmail.com>
> wrote:
>
>> @Yingyi, I\u2019m 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\u2019t need to spend
>> time to
>> implement a new generator.
>>
>>> On Feb 3, 2017, at 6:02 PM, Yingyi Bu <bu...@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.
>>
>>
Re: Choosing defaults for AsterixDB
Posted by Taewoo Kim <wa...@gmail.com>.
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 <ji...@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 <bu...@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.
>
>
Re: Choosing defaults for AsterixDB
Posted by Jianfeng Jia <ji...@gmail.com>.
@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 <bu...@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.
Re: Choosing defaults for AsterixDB
Posted by Yingyi Bu <bu...@gmail.com>.
>> I want to pick up this thread to verify if the AQL will still be
supported in the future?
AQL will still stay there.
However, "supported" might not be a 100% accurate term for an ASF open
source software.
Regardless of AQL or SQL++, if a user finds a bug or needs an improvement
in any place of the system, s/he can open an issue.
Then, if some committer/contributor is interested in fixing the bug, then
s/he submits a patch.
The process is volunteer or up to committers' interests. At least, that's
my understanding of how ASF software works.
This is very different from a paid enterprise software -- a reported bug or
a wanted feature from customers must be responded (and/or fixed):-)
Thoughts?
>> 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.
Best,
Yingyi
On Fri, Feb 3, 2017 at 5:37 PM, Jianfeng Jia <ji...@gmail.com> wrote:
> Hi, I want to pick up this thread to verify if the AQL will still be
> supported in the future?
> Currently, Cloudberry automatically translates the JSON request to AQL
> statements. It will be a hard work to switch to SQL++.
>
> I’m not object to set the default option to SQL++. However, we will keep
> the support for AQL, right? (especially in the RESTFull API).
>
> > On Jan 10, 2017, at 5:47 PM, Till Westmann <ti...@apache.org> wrote:
> >
> > Ok, since there’s a lot of agreement and no concerns, I’ll go ahead.
> >
> > Thanks,
> > Till
> >
> > On 10 Jan 2017, at 9:22, Yingyi Bu wrote:
> >
> >> +100!
> >>
> >> On Tue, Jan 10, 2017 at 9:17 AM, Mike Carey <dt...@gmail.com> wrote:
> >>
> >>> +1 from me too for SQL++ and clean JSON.
> >>>
> >>>
> >>>
> >>> On 1/10/17 8:25 AM, Murtadha Hubail wrote:
> >>>
> >>>> +1 to SQL++ and clean JSON.
> >>>>
> >>>> Cheers,
> >>>> Murtadha
> >>>>
> >>>> On Jan 10, 2017, at 9:46 AM, Till Westmann <ti...@apache.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> as you know AsterixDB supports 2 query languages (AQL and SQL++) and
> many
> >>>>> output formats (ADM, clean JSON, lossless JSON, CSV). Our current
> >>>>> defaults
> >>>>> for these options (at least on the web interface) are AQL and ADM.
> >>>>>
> >>>>> I’d like to propose to change those defaults to be SQL++ and (clean)
> >>>>> JSON.
> >>>>> The reason for wanting them to change, is that I think that these
> choices
> >>>>> are more attractive to new users of the system and thus can help to
> >>>>> increase
> >>>>> the adoption of AsterixDB. A user with some database experience is
> much
> >>>>> more
> >>>>> likely to have previous SQL experience and to feel at home with SQL++
> >>>>> than
> >>>>> having XQuery experience and feeling at home with AQL. Similarly,
> most
> >>>>> users
> >>>>> will want to use the data that they get out of AsterixDB in an
> >>>>> application
> >>>>> and it will be a lot easier to consume JSON than it is to consume
> ADM.
> >>>>>
> >>>>> I've prepared a (tiny) change to change the defaults [1] and I'm
> >>>>> wondering
> >>>>> if there are concerns that should keep us from making this change.
> >>>>>
> >>>>> Cheers,
> >>>>> Till
> >>>>>
> >>>>> [1] https://asterix-gerrit.ics.uci.edu/#/c/1409/
> >>>>>
> >>>>
> >>>
>
>
Re: Choosing defaults for AsterixDB
Posted by Jianfeng Jia <ji...@gmail.com>.
Hi, I want to pick up this thread to verify if the AQL will still be supported in the future?
Currently, Cloudberry automatically translates the JSON request to AQL statements. It will be a hard work to switch to SQL++.
I’m not object to set the default option to SQL++. However, we will keep the support for AQL, right? (especially in the RESTFull API).
> On Jan 10, 2017, at 5:47 PM, Till Westmann <ti...@apache.org> wrote:
>
> Ok, since there’s a lot of agreement and no concerns, I’ll go ahead.
>
> Thanks,
> Till
>
> On 10 Jan 2017, at 9:22, Yingyi Bu wrote:
>
>> +100!
>>
>> On Tue, Jan 10, 2017 at 9:17 AM, Mike Carey <dt...@gmail.com> wrote:
>>
>>> +1 from me too for SQL++ and clean JSON.
>>>
>>>
>>>
>>> On 1/10/17 8:25 AM, Murtadha Hubail wrote:
>>>
>>>> +1 to SQL++ and clean JSON.
>>>>
>>>> Cheers,
>>>> Murtadha
>>>>
>>>> On Jan 10, 2017, at 9:46 AM, Till Westmann <ti...@apache.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> as you know AsterixDB supports 2 query languages (AQL and SQL++) and many
>>>>> output formats (ADM, clean JSON, lossless JSON, CSV). Our current
>>>>> defaults
>>>>> for these options (at least on the web interface) are AQL and ADM.
>>>>>
>>>>> I’d like to propose to change those defaults to be SQL++ and (clean)
>>>>> JSON.
>>>>> The reason for wanting them to change, is that I think that these choices
>>>>> are more attractive to new users of the system and thus can help to
>>>>> increase
>>>>> the adoption of AsterixDB. A user with some database experience is much
>>>>> more
>>>>> likely to have previous SQL experience and to feel at home with SQL++
>>>>> than
>>>>> having XQuery experience and feeling at home with AQL. Similarly, most
>>>>> users
>>>>> will want to use the data that they get out of AsterixDB in an
>>>>> application
>>>>> and it will be a lot easier to consume JSON than it is to consume ADM.
>>>>>
>>>>> I've prepared a (tiny) change to change the defaults [1] and I'm
>>>>> wondering
>>>>> if there are concerns that should keep us from making this change.
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> [1] https://asterix-gerrit.ics.uci.edu/#/c/1409/
>>>>>
>>>>
>>>
Re: Choosing defaults for AsterixDB
Posted by Till Westmann <ti...@apache.org>.
Ok, since there\u2019s a lot of agreement and no concerns, I\u2019ll go ahead.
Thanks,
Till
On 10 Jan 2017, at 9:22, Yingyi Bu wrote:
> +100!
>
> On Tue, Jan 10, 2017 at 9:17 AM, Mike Carey <dt...@gmail.com> wrote:
>
>> +1 from me too for SQL++ and clean JSON.
>>
>>
>>
>> On 1/10/17 8:25 AM, Murtadha Hubail wrote:
>>
>>> +1 to SQL++ and clean JSON.
>>>
>>> Cheers,
>>> Murtadha
>>>
>>> On Jan 10, 2017, at 9:46 AM, Till Westmann <ti...@apache.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> as you know AsterixDB supports 2 query languages (AQL and SQL++)
>>>> and many
>>>> output formats (ADM, clean JSON, lossless JSON, CSV). Our current
>>>> defaults
>>>> for these options (at least on the web interface) are AQL and ADM.
>>>>
>>>> I\u2019d like to propose to change those defaults to be SQL++ and
>>>> (clean)
>>>> JSON.
>>>> The reason for wanting them to change, is that I think that these
>>>> choices
>>>> are more attractive to new users of the system and thus can help to
>>>> increase
>>>> the adoption of AsterixDB. A user with some database experience is
>>>> much
>>>> more
>>>> likely to have previous SQL experience and to feel at home with
>>>> SQL++
>>>> than
>>>> having XQuery experience and feeling at home with AQL. Similarly,
>>>> most
>>>> users
>>>> will want to use the data that they get out of AsterixDB in an
>>>> application
>>>> and it will be a lot easier to consume JSON than it is to consume
>>>> ADM.
>>>>
>>>> I've prepared a (tiny) change to change the defaults [1] and I'm
>>>> wondering
>>>> if there are concerns that should keep us from making this change.
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>> [1] https://asterix-gerrit.ics.uci.edu/#/c/1409/
>>>>
>>>
>>
Re: Choosing defaults for AsterixDB
Posted by Yingyi Bu <bu...@gmail.com>.
+100!
On Tue, Jan 10, 2017 at 9:17 AM, Mike Carey <dt...@gmail.com> wrote:
> +1 from me too for SQL++ and clean JSON.
>
>
>
> On 1/10/17 8:25 AM, Murtadha Hubail wrote:
>
>> +1 to SQL++ and clean JSON.
>>
>> Cheers,
>> Murtadha
>>
>> On Jan 10, 2017, at 9:46 AM, Till Westmann <ti...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> as you know AsterixDB supports 2 query languages (AQL and SQL++) and many
>>> output formats (ADM, clean JSON, lossless JSON, CSV). Our current
>>> defaults
>>> for these options (at least on the web interface) are AQL and ADM.
>>>
>>> I’d like to propose to change those defaults to be SQL++ and (clean)
>>> JSON.
>>> The reason for wanting them to change, is that I think that these choices
>>> are more attractive to new users of the system and thus can help to
>>> increase
>>> the adoption of AsterixDB. A user with some database experience is much
>>> more
>>> likely to have previous SQL experience and to feel at home with SQL++
>>> than
>>> having XQuery experience and feeling at home with AQL. Similarly, most
>>> users
>>> will want to use the data that they get out of AsterixDB in an
>>> application
>>> and it will be a lot easier to consume JSON than it is to consume ADM.
>>>
>>> I've prepared a (tiny) change to change the defaults [1] and I'm
>>> wondering
>>> if there are concerns that should keep us from making this change.
>>>
>>> Cheers,
>>> Till
>>>
>>> [1] https://asterix-gerrit.ics.uci.edu/#/c/1409/
>>>
>>
>
Re: Choosing defaults for AsterixDB
Posted by Mike Carey <dt...@gmail.com>.
+1 from me too for SQL++ and clean JSON.
On 1/10/17 8:25 AM, Murtadha Hubail wrote:
> +1 to SQL++ and clean JSON.
>
> Cheers,
> Murtadha
>
>> On Jan 10, 2017, at 9:46 AM, Till Westmann <ti...@apache.org> wrote:
>>
>> Hi,
>>
>> as you know AsterixDB supports 2 query languages (AQL and SQL++) and many
>> output formats (ADM, clean JSON, lossless JSON, CSV). Our current defaults
>> for these options (at least on the web interface) are AQL and ADM.
>>
>> I\u2019d like to propose to change those defaults to be SQL++ and (clean) JSON.
>> The reason for wanting them to change, is that I think that these choices
>> are more attractive to new users of the system and thus can help to increase
>> the adoption of AsterixDB. A user with some database experience is much more
>> likely to have previous SQL experience and to feel at home with SQL++ than
>> having XQuery experience and feeling at home with AQL. Similarly, most users
>> will want to use the data that they get out of AsterixDB in an application
>> and it will be a lot easier to consume JSON than it is to consume ADM.
>>
>> I've prepared a (tiny) change to change the defaults [1] and I'm wondering
>> if there are concerns that should keep us from making this change.
>>
>> Cheers,
>> Till
>>
>> [1] https://asterix-gerrit.ics.uci.edu/#/c/1409/
Re: Choosing defaults for AsterixDB
Posted by Murtadha Hubail <mh...@apache.org>.
+1 to SQL++ and clean JSON.
Cheers,
Murtadha
> On Jan 10, 2017, at 9:46 AM, Till Westmann <ti...@apache.org> wrote:
>
> Hi,
>
> as you know AsterixDB supports 2 query languages (AQL and SQL++) and many
> output formats (ADM, clean JSON, lossless JSON, CSV). Our current defaults
> for these options (at least on the web interface) are AQL and ADM.
>
> I’d like to propose to change those defaults to be SQL++ and (clean) JSON.
> The reason for wanting them to change, is that I think that these choices
> are more attractive to new users of the system and thus can help to increase
> the adoption of AsterixDB. A user with some database experience is much more
> likely to have previous SQL experience and to feel at home with SQL++ than
> having XQuery experience and feeling at home with AQL. Similarly, most users
> will want to use the data that they get out of AsterixDB in an application
> and it will be a lot easier to consume JSON than it is to consume ADM.
>
> I've prepared a (tiny) change to change the defaults [1] and I'm wondering
> if there are concerns that should keep us from making this change.
>
> Cheers,
> Till
>
> [1] https://asterix-gerrit.ics.uci.edu/#/c/1409/