← Back to team overview

oqgraph-dev team mailing list archive

Re: supporting oqgraph in MariaDB 5.5.32

 

On 09/16/2013 05:59 AM, Andrew McDonnell wrote:> Hello Tom,
> Looking at your paste-bin, it appears that the errors are due to changes in
> the internal storage engine API that occured between 5.5 and 10.0. I was beset
> with similar errors when I recently merged several months worth of progress
> from the lp:maria/10.0 branch into the oqgraph v3 branch...
> I am now addressing this, starting by doing what you did - I forked
> pkg-mariadb and copied storage/oqgraph over the top, and am currently working
> through fixing the build issues with #ifdefs.

Excellent, thanks!

> Hopefully this will then let v3 work with both 5.5.32 and 10.0 by simply
> forking the storage/oqgraph directory.
>
> If I can get it running I'll ask for a pull request from my github. Then I'll
> merge my changes back to launchpad.  Whether it runs without failing any
> rgeression tests remain to be seen, I dont know what other changes have
> happened to 10.0.4 that might have an impact

Per my followup message... Is there any way oqgraph could be made to
be a plugin (as in the older version which did ./configure --mysql=/path/to/mysql )?
In that way you could inspect the DB headers and "do the right thing"
based on 5.5 vs. 10.0.

> The way I run the test suite is by doing an in-place build of maria, then
> executing
>
>     mysql-test/mysql-test-run --suite=oqgraph

Thanks!  I should have thought of that!

> There is a test mysql-test/suite/oqgraph/social.tets, I am guessing this is
> what Arjen is referring to, it creates a 10000 node multi-linked graph.
>
> You can run individually with
>
>     mysql-test/mysql-test-run oqgraph.social

Cool!

> I am unsure how this would be run in the debian packaging environment.  To
> date I have done all my development in a local build.  To do development, I
> simply do the following in the source tree:
>
>     mkdir build && cd build
>     cmake .. -DWITH_EXTRA_CHARSETS=complex
> -DWITH_PLUGIN_ARIA=1-DWITH_READLINE=1 -DWITH_SSL=bundled -DWITH_MAX=1
> -DWITH_EMBEDDED_SERVER=1
>     mysql-test/mysql-test-run --suite=oqgraph
>
> The way I tested with boost 1.54 was to install boost locally so as not to
> conflict with the Wheezy dpkg, then
>
>     cmake .. -DWITH_EXTRA_CHARSETS=complex
> -DWITH_PLUGIN_ARIA=1-DWITH_READLINE=1 -DWITH_SSL=bundled -DWITH_MAX=1
> -DWITH_EMBEDDED_SERVER=1 -DBOOST_ROOT=$HOME/opt/boost-1.54
> -DBoost_NO_SYSTEM_PATHS=ON
>     (etc)

That sounds like a good way to test the 1.54 issue.

> I will need to see if I can backport 1.54 against wheezy to see how it goes
> against the sid packaging

Installing a newer version of boost on wheezy (as you mentioned above) sounds
like the way to test this... what do you mean by backporting?
You don't mean "repackaging boost 1.54 for wheezy" do you?

On 09/16/2013 07:17 AM, Andrew McDonnell wrote:
> An update:
> 
> I have managed a successful build of 5.5.32 with #ifdefs on wheezy, so far so
> good.

Excellent. Are you checking your code in somewhere? I'd like to try to
build in parallel to you.

Are you thinking of this repo for the MariaDB 5.5.32 build?
  https://github.com/andymc73/pkg-mariadb

> Regarding the test suite -
> 
> Actually it looks like the debian package build runs all the maria test suite
> at conclusion, so it should automatically run the oqgraph suite... although it
> is currently estimating 4(!) hours for the entire suite so I think I will kill
> it and start again before I go to bed.

Yes, we like to be, um, thorough :)
Right now the challenge we have is getting oqgraph to build
against both 5.5 and 10.0 -- then we can worry about testing.

> One thing to note is that maria1.0 chaned the output of errors and warnings:
> In 5.5 you see "Can't create table 'test.graph'" but in 10.0 "Can't create
> table `test`.`graph`", 10.0 also adds amplifying information.
> From reading the mtr manual I cant work out how to have alternate results
> files for different mysql versions.  This results in my test result files
> failing spuriously.
> To workaround for now I have patched these in my git fork, but they probably
> need to be fixed using debian patches or something.

We could do that with debian patches... But if oqgraph were
a separate package (as a plugin) then we could set the test
against the relevant version of the DB. I imagine one plugin
package per version, for example 'mariadb-5-5-oqgraph' and 'mariadb-10-oqgraph'.

> Next step is to pull down 1.54 from sid and repeat the above...

In fact the advantage to building on unstable (sid) is that
you get the entire up-to-date toolchain for free (not just boost).
You can download the released MariaDB tarballs:
  https://downloads.mariadb.org/

And then drop in the storage/oqgraph directory (if built-in)
or work on the separate plugin version.

NOTE: The only differences between the Otto git repo and the
released MariaDB tarball are captured in the patches directory:
  https://github.com/ottok/pkg-mariadb/tree/master/debian/patches
But I don't think these are significant for testing/debugging oqgraph.

Regards,

--Tom




Follow ups

References