maria-developers team mailing list archive

[Daniel Black <daniel.black@xxxxxxxxxxxxx>]

Just letting you know I tried going down this path.

as FederatedX there's a lot SQL pushed across that sphinxql doesn't support - http://sphinxsearch.com/bugs/view.php?id=1950
aside form FederatedX retrieving the entire dataset to do an update.

sphinxql urls require a specific table structure that I couldn't work out - http://sphinxsearch.com/bugs/view.php?id=1952

My general impression is sphinxse needs to be totally rewritten as using the sphinx client library.


----- Original Message -----
> Hello Sergey,
> 
> is there any progress with the patch or could i do something to help
> you?
> 
> Thank you very much!
> 
> 
> Best regards,
> 
> 
> Markus Lidel
> 
> 
> 
> Am 09.04.2014 09:51, schrieb Sergey Vojtovich:
> > Hi Markus,
> >
> > sorry for this delay. I was going to check with other developers
> > regarding your
> > patch but apparently it didn't happen.
> >
> > Sergei, could you review this contribution and send back your
> > suggestions?
> > I believe most of this stuff should be implemented in sphinx, but
> > you may
> > have different opinion.
> >
> > Thanks,
> > Sergey
> >
> > On Tue, Apr 08, 2014 at 11:38:42AM +0200, Markus Lidel wrote:
> >> Hello Sergey,
> >>
> >> is there any progress with the patch or is there still something
> >> missing?
> >>
> >>
> >> Thank you very much!
> >>
> >>
> >> Best regards,
> >>
> >>
> >> Markus Lidel
> >>
> >> Am 16.06.2013 19:58, schrieb Markus Lidel:
> >>> Hello Sergey,
> >>>
> >>> thank you very much for reviewing my patch!
> >>>
> >>> Am 16.06.2013 15:48, schrieb Sergey Vojtovich:
> >>>> Hi Markus,
> >>>>
> >>>> thanks for your contribution. Connecting to Sphinx RT index via
> >>>> federatedx
> >>>> sounds like a great idea.
> >>>>
> >>>> I reviewed attached patch and from what I can see, relevant
> >>>> difference
> >>>> between dialects is as following:
> >>>>
> >>>> 1. Connection to RT index doesn't require database name and you
> >>>> made it
> >>>>     optional in parse_url(). That's acceptable with sphinxql
> >>>>     scheme, but
> >>>>     with mysql scheme it's a bit ambiguous. What do you think if
> >>>>     we keep
> >>>>     database name mandatory and document that connection string
> >>>>     to RT
> >>>> index
> >>>>     should look like
> >>>>     sphinxql://root@localhost:9306//rt
> >>>>     or
> >>>>     sphinxql://root@localhost:9306/dummy/rt
> >>>
> >>> Hmmm, i think both ways are a workaround. Probably the best way is
> >>> to
> >>> implement a unique parse_url() function for sphinxql and mysql.
> >>> This way
> >>> you don't have to specify a database, which isn't used for
> >>> SphinxQL and
> >>> for MySQL you couldn't forget to set the database. The only reason
> >>> why i
> >>> didn't implement it already was because i want to change as less
> >>> as
> >>> possible. I'll look into it and send an updated patch.
> >>>
> >>>> 2. delete_row(): looks nice, but could be greatly simplified
> >>>> because
> >>>> sphinxql
> >>>>     accepts only record identifier in WHERE clause.
> >>>
> >>> Yes, that's true.
> >>>
> >>>> 3. delete_all_rows(): FWICS there is "TRUNCATE RTINDEX" statement
> >>>> in
> >>>> sphinx.
> >>>>     Why can't we use it? Even better patch sphinx to make RTINDEX
> >>>>     word
> >>>> optional?
> >>>
> >>> TRUNCATE RTINDEX was implemented first in Sphinx 2.1.1-beta. In
> >>> the
> >>> current release the TRUNCATE RTINDEX is not available.
> >>>
> >>>> 4. table_metadata(): I believe it should be easy and natural to
> >>>> patch
> >>>> sphinx to
> >>>>     support SHOW TABLE STATUS. What do you think?
> >>>
> >>> Yes, that will be the best solution, but i didn't looked at the
> >>> source
> >>> of Sphinx.
> >>>
> >>>> 5. query(): Same here, sphinxql shouldn't add implicit limit.
> >>>
> >>> SphinxQL by default adds a limit to 30 rows. So if you don't
> >>> specify a
> >>> LIMIT you only get 30 rows back instead of all rows. If you for
> >>> example
> >>> have 100 rows in your Sphinx index, and you want to delete all
> >>> rows, you
> >>> could only delete 30 at once. So i thought the best way is to add
> >>> a limit.
> >>>
> >>>> 6. test_connection(): What's the problem with test query?
> >>>
> >>> Sphinx simply doesn't understand the test query:
> >>>
> >>> SELECT * FROM <table> WHERE 1=0
> >>>
> >>> so i changed it into
> >>>
> >>> SELECT * FROM <table> LIMIT 0
> >>>
> >>> which should do the same, and Sphinx did understand.
> >>>
> >>>> Did I miss anything else?
> >>>
> >>> If so, please feel free to contact me.
> >>>
> >>>
> >>> Best regards,
> >>>
> >>>
> >>> Markus Lidel
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>> Sergey
> >>>>
> >>>> 29.05.2013, в 1:46, Markus Lidel <Markus.Lidel@xxxxxxxxxxxxxxxxx>
> >>>> написал(а):
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> the Sphinx Search engine has RT indexes, which could be updated
> >>>>> with
> >>>>> a subset of SQL commands, refered to as SphinxQL:
> >>>>>
> >>>>> http://sphinxsearch.com/docs/2.1.1/sphinxql-reference.html
> >>>>>
> >>>>> Because the FederatedX storage engine uses some commands, which
> >>>>> Sphinx does not know, here is a patch, wich extends the
> >>>>> FederatedX
> >>>>> storage engine to support this subset of commands. Now its
> >>>>> possible
> >>>>> to update Sphinx RT indexes directly from MariaDB. To create a
> >>>>> connection to the RT index in the Sphinx default RT-index:
> >>>>>
> >>>>> index rt
> >>>>> {
> >>>>>   type = rt
> >>>>>
> >>>>>   path = @CONFDIR@/data/rt
> >>>>>
> >>>>>   rt_field = title
> >>>>>   rt_field = content
> >>>>>
> >>>>>   rt_attr_string = title
> >>>>>   rt_attr_string = content
> >>>>>
> >>>>>   rt_attr_uint = gid
> >>>>> }
> >>>>>
> >>>>> you just have to call:
> >>>>>
> >>>>> CREATE TABLE `rt` (
> >>>>>   `id` BIGINT UNSIGNED NOT NULL,
> >>>>>   `title` TEXT,
> >>>>>   `content` TEXT,
> >>>>>   `gid` INT UNSIGNED
> >>>>> ) ENGINE=FEDERATED
> >>>>> CONNECTION='sphinxql://root@localhost:9306/rt';
> >>>>>
> >>>>> It would be great, if the attached patch could be integrated
> >>>>> into
> >>>>> MariaDB. If you have any suggestions, please feel free to
> >>>>> contact me.
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>>
> >>>>> Markus Lidel
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-developers
> Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help : https://help.launchpad.net/ListHelp

-- 
-- 
Daniel Black, Engineer @ Open Query (http://openquery.com.au)
Remote expertise & maintenance for MySQL/MariaDB server environments.