asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taewoo Kim <wangs...@gmail.com>
Subject Re: Function name change: contains() -> string-contains()
Date Thu, 15 Sep 2016 21:48:49 GMT
@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 <buyingyi@gmail.com> 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
> 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 FunctionMapUtil.java for SQL++ as "contains" should stay as a SQL++
> builtin function (like Oracle SQL).
> Thanks!
>
> Best,
> Yingyi
>
> On Thu, Sep 15, 2016 at 2:40 PM, Taewoo Kim <wangsaeu@gmail.com> wrote:
>
> > @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, Yingyi Bu <buyingyi@gmail.com> wrote:
> >
> > > 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
> > > syntax is translated into fulltext functions by the language
> translator,
> > we
> > > can easily support them in SQL++.
> > >
> > > Best,
> > > Yingyi
> > >
> > >
> > > On Thu, Sep 15, 2016 at 2:20 PM, Taewoo Kim <wangsaeu@gmail.com>
> 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 check the following sheet to see how other systems
> > do.
> > > >
> > > > https://docs.google.com/spreadsheets/d/1j6_YSCc_
> > > > 8gEReAWFP84geI30wlnsz7uMFq4TCm7GRz8/edit?usp=sharing
> > > >
> > > > MySQL: match(), against()
> > > > Oracle: contains(), catsearch(), matches()
> > > > MongoDB: $text
> > > > AsterixDB: follows XQuery spec(e.g., $o.title *contains text*
> "hello")
> > > >
> > > >
> > > >
> > > >
> > > > Best,
> > > > Taewoo
> > > >
> > > > On Thu, Sep 15, 2016 at 2:07 PM, Taewoo Kim <wangsaeu@gmail.com>
> > wrote:
> > > >
> > > > > 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 <chillery@lambda.nu
> >
> > > > wrote:
> > > > >
> > > > >> 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" <wangsaeu@gmail.com>
wrote:
> > > > >>
> > > > >> > 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
> > > > >> > change:
> > > > >> >
> > > > >> > On Wed, Mar 2, 2016 at 6:25 PM, Taewoo Kim <wangsaeu@gmail.com>
> > > > wrote:
> > > > >> >
> > > > >> > > Hello All,
> > > > >> > >
> > > > >> > > I would like to suggest a current function name change.
I am
> > > > currently
> > > > >> > > working on Full Text Search features. XQuery Full-text
search
> > spec
> > > > [1]
> > > > >> > > states that for a full-text search, the syntax is *RangeExpr
(
> > > > >> "contains"
> > > > >> > > "text" FTSelection FTIgnoreOption? )?*. As you see,
we are
> going
> > > to
> > > > >> use
> > > > >> > > "contains text something". And we already have contains()
> > function
> > > > [2]
> > > > >> > that
> > > > >> > > does a substring match.  So, in order to remove possible
> > > ambiguities
> > > > >> > > between two features, *contains()* will be renamed
to
> > > > >> *string-contains()*
> > > > >> > > when I merge my index-only branch to the master if
there is no
> > > > strong
> > > > >> > > opinion on this. Thank you. I will send another note
as my
> merge
> > > > >> > > progresses. Thank you.
> > > > >> > >
> > > > >> > > [1] https://www.w3.org/TR/xpath-full-text-10/#doc-xquery10-
> > > > >> > FTContainsExpr
> > > > >> > >
> > > > >> > > [2] https://asterix-jenkins.ics.
> uci.edu/job/asterix-test-full/
> > > > >> > > site/asterix-doc/aql/functions.html#StringFunctions
> > > > >> > >
> > > > >> > > Best,
> > > > >> > > Taewoo
> > > > >> > >
> > > > >> >
> > > > >> > Thank you.
> > > > >> >
> > > > >> > Best,
> > > > >> > Taewoo
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message