asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yingyi Bu <buyin...@gmail.com>
Subject Re: Function name change: contains() -> string-contains()
Date Thu, 15 Sep 2016 21:53:19 GMT
All right, thanks!

Best,
Yingyi

On Thu, Sep 15, 2016 at 2:48 PM, Taewoo Kim <wangsaeu@gmail.com> 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 <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