+1
On Fri, Sep 16, 2016 at 3:36 PM, Mike Carey wrote:
> +2 :-)
>
>
>
> On 9/16/16 2:06 PM, Yingyi Bu wrote:
>
>> Cool, +1!
>>
>> Best,
>> Yingyi
>>
>> On Fri, Sep 16, 2016 at 1:54 PM, Taewoo Kim wrote:
>>
>> So, in summary, we agree to use a function format for the full-text
>>> search,
>>> ra
+2 :-)
On 9/16/16 2:06 PM, Yingyi Bu wrote:
Cool, +1!
Best,
Yingyi
On Fri, Sep 16, 2016 at 1:54 PM, Taewoo Kim wrote:
So, in summary, we agree to use a function format for the full-text search,
rather than using XQuery syntax. "contains" doesn't have to be
"string-contains" and "text" doe
Cool, +1!
Best,
Yingyi
On Fri, Sep 16, 2016 at 1:54 PM, Taewoo Kim wrote:
> So, in summary, we agree to use a function format for the full-text search,
> rather than using XQuery syntax. "contains" doesn't have to be
> "string-contains" and "text" doesn't have to be a reserved word.
>
> The pos
+1
On 16 Sep 2016, at 13:54, Taewoo Kim wrote:
So, in summary, we agree to use a function format for the full-text
search,
rather than using XQuery syntax. "contains" doesn't have to be
"string-contains" and "text" doesn't have to be a reserved word.
The possible syntax would be:
*ftcontains
So, in summary, we agree to use a function format for the full-text search,
rather than using XQuery syntax. "contains" doesn't have to be
"string-contains" and "text" doesn't have to be a reserved word.
The possible syntax would be:
*ftcontains*(expression1, expression2, parameter record express
+1
-heri
> On Sep 15, 2016, at 19:01, Chen Li wrote:
>
> For full-text search, I like "ftcontains()" since it's very intuitive.
>
> Syntax for advanced full-text features such as stop words, analyzers, and
> languages need a separate discussion.
>
> Chen
>
> On Thu, Sep 15, 2016 at 5:58 PM,
If we choose ftcontains() or matches(), then I think we may keep contains()
as it is. And since we choose a function form, 'text' doesn't have to be a
reserved keyword. Then, at this stage, we don't need to change anything to
integrate the full-text search feature.
One remaining issue as Chen said
For full-text search, I like "ftcontains()" since it's very intuitive.
Syntax for advanced full-text features such as stop words, analyzers, and
languages need a separate discussion.
Chen
On Thu, Sep 15, 2016 at 5:58 PM, Taewoo Kim wrote:
> @Till: I see. Thanks for the suggestion. It's more cl
@Till: I see. Thanks for the suggestion. It's more clearer now.
Best,
Taewoo
On Thu, Sep 15, 2016 at 5:58 PM, Till Westmann wrote:
> And as it turns out, we already have some infrastructure to translate a
> constant record constructor expression into a record in
> LangRecordParseUtil.
> So supp
And as it turns out, we already have some infrastructure to translate a
constant record constructor expression into a record in
LangRecordParseUtil.
So supporting that wouldn’t be too painful.
Cheers,
Till
On 15 Sep 2016, at 17:41, Till Westmann wrote:
One option to express those parameters,
If we "wanted" a keyword approach like XQuery, I'd vote for matches (to
replace text).
On 9/15/16 2:20 PM, Taewoo Kim wrote:
I just talked to Mike to resolve 'text' and he suggested an idea to check
what other systems do. Fortunately, we have collected the information some
time ago. You can ch
One option to express those parameters, would be to pass in a (compile
time
constant) record/object. E.g.
where ftcontains($o.title, ["hello","hi"],
{ "combine": "and", "stop list": "default" })
That way we could have named optional parameters (please ignore the
ugline
@Till: we can add whether the given search is AND/OR search, stop list
and/or stemming method. For example, if we use ftcontains(), then it might
look like:
1) where ftcontains($o.title, "hello"): find $o where the title field
contains hello.
2) where ftcontains($o.title, ["hello","hi"], any): fin
Makes sense to me (especially as I always think about this specific one
as
"ftcontains" :) ).
Another thing you mentioned is about the parameters that will get added
in the
future. Could you provide an example for this?
Cheers,
Till
On 15 Sep 2016, at 15:37, Taewoo Kim wrote:
Maybe we could
Maybe we could come up with a function form - *ftcontains*(). Here, ft is
an abbreviation for full-text. This function replaces "contains text" in
XQuery spec. An example might be:
XQuery spec: where $o.titile contains text "hello"
AQL: where ftcontains($o.title, "hello")
Best,
Taewoo
On Thu,
@Yingyi: Great. Thanks.
Best,
Taewoo
On Thu, Sep 15, 2016 at 3:15 PM, Yingyi Bu wrote:
> Done.
>
> Best,
> Yingyi
>
> On Thu, Sep 15, 2016 at 2:43 PM, Taewoo Kim wrote:
>
> > @Yingyi: Good to know that! I just gave you the permission to edit
> > document. Please edit it as needed since I'm not
@Till: Got it. I agree to your opinion. The issue here for the full-text
search is that many function parameters that controls the behavior of
full-text search will be added in the future. Maybe this is not the issue?
:-)
Best,
Taewoo
On Thu, Sep 15, 2016 at 3:11 PM, Till Westmann wrote:
> Hi,
Done.
Best,
Yingyi
On Thu, Sep 15, 2016 at 2:43 PM, Taewoo Kim wrote:
> @Yingyi: Good to know that! I just gave you the permission to edit
> document. Please edit it as needed since I'm not familiar with every
> functions, just some that you mentioned.
>
> Best,
> Taewoo
>
> On Thu, Sep 15, 201
Hi,
I think that our challenge here is, that XQuery is very liberal in the
introduction of new keywords, as the grammar is keyword free. However,
they
often use combinations of words "contain" "text" to disambiguate.
AQL on the other had is not keyword free and so each time we introduce a
new
All right, thanks!
Best,
Yingyi
On Thu, Sep 15, 2016 at 2:48 PM, Taewoo Kim wrote:
> @Yingyi: will add the mapping for "string-contains()" in AQL and
> "contains()" in SQL++.
>
> Best,
> Taewoo
>
> On Thu, Sep 15, 2016 at 2:45 PM, Yingyi Bu wrote:
>
> > All right, if the AQL surface doesn't le
@Yingyi: will add the mapping for "string-contains()" in AQL and
"contains()" in SQL++.
Best,
Taewoo
On Thu, Sep 15, 2016 at 2:45 PM, Yingyi Bu wrote:
> All right, if the AQL surface doesn't lead to special tweaks in the
> compiler, e.g., rewriting rules, the same infrastructure can be used for
All right, if the AQL surface doesn't lead to special tweaks in the
compiler, e.g., rewriting rules, the same infrastructure can be used for
SQL++.
I'm OK with the AQL function name change from contains() to
string-contains(), however you'll need map "contains" to "string-contains"
in FunctionMapU
@Yingyi: Good to know that! I just gave you the permission to edit
document. Please edit it as needed since I'm not familiar with every
functions, just some that you mentioned.
Best,
Taewoo
On Thu, Sep 15, 2016 at 2:40 PM, Yingyi Bu wrote:
> Hi Taewoo,
>
> Recently I have added several str
@Yingyi: Yes. It's just a syntactic sugar - it can be anything:
"contains_text", "contains text" or "containstext". It would be nice if
one form of function is used for both AQL and SQL++. Currently, to follow
the Xquery spec, this doesn't work.
Best,
Taewoo
On Thu, Sep 15, 2016 at 2:27 PM, Ying
Hi Taewoo,
Recently I have added several string functions into *DB:
initcap(title),
regexp_like,
regexp_position,
ltrim,
trim,
rtrim,
position,
repeat,
split
(Replace '_' with '-' in function names for AQL.)
You can add them to the Aster
Hi Taewoo,
Are those fulltext search syntax extensions are only a syntactic sugar
(i.e., surface) thing that is translated into functions?
In a not-too-distant-future, we will need to surface fulltext search in
SQL++, probably using the same functions like Oracle. If the AQL fulltext
synta
I just talked to Mike to resolve 'text' and he suggested an idea to check
what other systems do. Fortunately, we have collected the information some
time ago. You can check the following sheet to see how other systems do.
https://docs.google.com/spreadsheets/d/1j6_YSCc_8gEReAWFP84geI30wlnsz7uMFq4T
There are many test cases that use *text* as one of its field name. We can
correct it using 'text' or `text`. But, if a user currently uses *text* as
its a field name of a dataset, then, clearly, yes, it will not work.
Best,
Taewoo
On Thu, Sep 15, 2016 at 2:02 PM, Chris Hillery wrote:
> Making
Making "text" a reserved word seems like a more breaking change than the
function names, doesn't it?
Ceej
aka Chris Hillery
On Sep 15, 2016 1:57 PM, "Taewoo Kim" wrote:
> Reminder:
>
> Related to the full-text search, a string function named *contains*() will
> be renamed to *string-contains*()
Reminder:
Related to the full-text search, a string function named *contains*() will
be renamed to *string-contains*() soon. Also, "*text*" will become a
reserved word just like "for" or "where". It will happen soon as the first
step to the full-text search merge. Here are more details about this
30 matches
Mail list logo
