MediaWiki unit testing and non-MySQL databases

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

MediaWiki unit testing and non-MySQL databases

Brion Vibber-3
Hey all --

I've got a stack of issues discussed during the last couple months'
conferences and hackathons to raise, so there may be a few more manifestos
on the way. But don't worry, this one will be short!


I had a great chat at the New Orleans hackathon with D J Bauch who's been
working on maintaining MediaWiki's MS SQL Server support, and also had a
very useful email chat a couple weeks back with Freakalowsky who's put a lot
of work into MediaWiki's Oracle support.

Long story short: though traditionally MediaWiki developers have put very
little work on our own into maintaining non-MySQL compatibility, there's
still lots of folks interested in running on them... AND THEY ACTUALLY
MOSTLY WORK!

At this point I think it's a bit crazy of us to keep on marginalizing that
code; some folks running their own instances will need or want or prefer (or
be forced by office IT) to run on some "funny" database, and we shouldn't
stand in their way. More importantly, keeping things working with multiple
DB backends helps us to keep our code cleaner, and reduces our own hard
dependencies on a particular product line.


There are two main impediments to keeping code working on non-MySQL
platforms:
* lazy code breakages -- us MySQL-natives accidentally use MySQL-isms that
break queries on other platforms
* lazy schema updates -- us MySQL-natives add new schema updates into the
system but only implement them for MySQL

The first could often be helped simply by having automated testing run to
make sure that relevant code paths get exercised. Often there's just a
function that's used, or lazy use of LIMIT/OFFSET, or GROUP BY in a form
that other databases are pickier about. Just flagging them from the testing
can often be enough to make it easy to fix.

The second is a bit harder, but again testing can help flag that something
needs to be updated so it doesn't wait until too late for the next release,
or something.


I'd like for everybody who's working on MediaWiki on non-MySQL databases to
make sure that the phpunit test suite can run on your favorite platform, so
we can see about getting them set up in our regular reports on
http://integration.mediawiki.org/ci/

Green bars are your friend! :)

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Chad
On Mon, Oct 24, 2011 at 3:04 PM, Brion Vibber <[hidden email]> wrote:
> I'd like for everybody who's working on MediaWiki on non-MySQL databases to
> make sure that the phpunit test suite can run on your favorite platform, so
> we can see about getting them set up in our regular reports on
> http://integration.mediawiki.org/ci/
>

Jenkins already runs the tests using Sqlite. Adding Mysql would be
pretty trivial. Postgres too, probably.

I'm not so sure about getting Oracle, DB2 and MSSQL up and running
on gallium ;-)

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Russell Nelson-3
Is there a way to tell Sqlite to be pickier about what it will accept? If it
bombs out on anything that falls outside the union of (all supported
database SQL), then just passing our tests should be sufficient, right?

On Mon, Oct 24, 2011 at 3:15 PM, Chad <[hidden email]> wrote:

> On Mon, Oct 24, 2011 at 3:04 PM, Brion Vibber <[hidden email]> wrote:
> > I'd like for everybody who's working on MediaWiki on non-MySQL databases
> to
> > make sure that the phpunit test suite can run on your favorite platform,
> so
> > we can see about getting them set up in our regular reports on
> > http://integration.mediawiki.org/ci/
> >
>
> Jenkins already runs the tests using Sqlite. Adding Mysql would be
> pretty trivial. Postgres too, probably.
>
> I'm not so sure about getting Oracle, DB2 and MSSQL up and running
> on gallium ;-)
>
> -Chad
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Mark A. Hershberger
In reply to this post by Brion Vibber-3
Brion Vibber <[hidden email]> writes:

> I'd like for everybody who's working on MediaWiki on non-MySQL databases to
> make sure that the phpunit test suite can run on your favorite platform, so
> we can see about getting them set up in our regular reports on
> http://integration.mediawiki.org/ci/

It'd be great if you can also review and update
http://www.mediawiki.org/wiki/Database_testing as needed.

Mark.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Fred Zimmerman-2
In reply to this post by Brion Vibber-3
while we're on the subject, a question about MySQL: is it possible to make
MW independent of MySQL innodb tables? Innodb tables have a number of
attributes that can make set up a pain (e.g. file and log sizes).

On Mon, Oct 24, 2011 at 2:04 PM, Brion Vibber <[hidden email]> wrote:

> Hey all --
>
> I've got a stack of issues discussed during the last couple months'
> conferences and hackathons to raise, so there may be a few more manifestos
> on the way. But don't worry, this one will be short!
>
>
> I had a great chat at the New Orleans hackathon with D J Bauch who's been
> working on maintaining MediaWiki's MS SQL Server support, and also had a
> very useful email chat a couple weeks back with Freakalowsky who's put a
> lot
> of work into MediaWiki's Oracle support.
>
> Long story short: though traditionally MediaWiki developers have put very
> little work on our own into maintaining non-MySQL compatibility, there's
> still lots of folks interested in running on them... AND THEY ACTUALLY
> MOSTLY WORK!
>
> At this point I think it's a bit crazy of us to keep on marginalizing that
> code; some folks running their own instances will need or want or prefer
> (or
> be forced by office IT) to run on some "funny" database, and we shouldn't
> stand in their way. More importantly, keeping things working with multiple
> DB backends helps us to keep our code cleaner, and reduces our own hard
> dependencies on a particular product line.
>
>
> There are two main impediments to keeping code working on non-MySQL
> platforms:
> * lazy code breakages -- us MySQL-natives accidentally use MySQL-isms that
> break queries on other platforms
> * lazy schema updates -- us MySQL-natives add new schema updates into the
> system but only implement them for MySQL
>
> The first could often be helped simply by having automated testing run to
> make sure that relevant code paths get exercised. Often there's just a
> function that's used, or lazy use of LIMIT/OFFSET, or GROUP BY in a form
> that other databases are pickier about. Just flagging them from the testing
> can often be enough to make it easy to fix.
>
> The second is a bit harder, but again testing can help flag that something
> needs to be updated so it doesn't wait until too late for the next release,
> or something.
>
>
> I'd like for everybody who's working on MediaWiki on non-MySQL databases to
> make sure that the phpunit test suite can run on your favorite platform, so
> we can see about getting them set up in our regular reports on
> http://integration.mediawiki.org/ci/
>
> Green bars are your friend! :)
>
> -- brion
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Danny Joe Bauch
In reply to this post by Mark A. Hershberger
I will work on that (getting the phpunit test suite up and  running on
my box) next. Historically, I have had the good fortune of watching
spectacular failures without even having had to resort to phpunit, but
I'm working toward resolving that.

On Mon, Oct 24, 2011 at 3:50 PM, Mark A. Hershberger
<[hidden email]> wrote:

> Brion Vibber <[hidden email]> writes:
>
>> I'd like for everybody who's working on MediaWiki on non-MySQL databases to
>> make sure that the phpunit test suite can run on your favorite platform, so
>> we can see about getting them set up in our regular reports on
>> http://integration.mediawiki.org/ci/
>
> It'd be great if you can also review and update
> http://www.mediawiki.org/wiki/Database_testing as needed.
>
> Mark.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Chad
In reply to this post by Fred Zimmerman-2
On Mon, Oct 24, 2011 at 5:08 PM, Fred Zimmerman <[hidden email]> wrote:
> while we're on the subject, a question about MySQL: is it possible to make
> MW independent of MySQL innodb tables? Innodb tables have a number of
> attributes that can make set up a pain (e.g. file and log sizes).
>

$wgDBTableOptions.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Ben Lobaugh (CompuCom Systems Inc)
I smell another abstraction layer coming on...

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chad
Sent: Monday, October 24, 2011 2:19 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] MediaWiki unit testing and non-MySQL databases

On Mon, Oct 24, 2011 at 5:08 PM, Fred Zimmerman <[hidden email]> wrote:
> while we're on the subject, a question about MySQL: is it possible to
> make MW independent of MySQL innodb tables? Innodb tables have a
> number of attributes that can make set up a pain (e.g. file and log sizes).
>

$wgDBTableOptions.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Brion Vibber
In reply to this post by Fred Zimmerman-2
On Mon, Oct 24, 2011 at 2:08 PM, Fred Zimmerman <[hidden email]>wrote:

> while we're on the subject, a question about MySQL: is it possible to make
> MW independent of MySQL innodb tables? Innodb tables have a number of
> attributes that can make set up a pain (e.g. file and log sizes).
>

There should be nothing relying specifically on InnoDB that I know of; we
default to InnoDB for everything possible because it's the only sane table
type widely available on standard MySQL installs (and it should fall back to
whetever the server default is if you don't have InnoDB).

If you do choose to use non-InnoDB tables, I recommend using something else
that is designed to work with transactions and survive server crashes (eg,
DO NOT USE MyISAM)

As noted in other replies, you can tweak $wgDBTableOptions to change the
default table type used when creating new tables; you can change existing
ones with an ALTER TABLE at any time.

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Platonides
In reply to this post by Russell Nelson-3
Russell Nelson wrote:
> Is there a way to tell Sqlite to be pickier about what it will accept? If it
> bombs out on anything that falls outside the union of (all supported
> database SQL), then just passing our tests should be sufficient, right?

No. And even if it didn't had its own laxitude (eg. accepting text in a
numeric field), the abstraction layer would still be different, so you
would also need to test that.



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Freako F. Freakolowsky
In reply to this post by Brion Vibber-3
I'll have a look(haven't poked the phpunit code for a while now) to make
sure it's operational on Oracle backend.

@Chad: if the issue is in the DB itself (i inderstand that running it
can be somewhat of a pain) i could try to get you access to one of out
sandbox instances for the purposes of CI. Might not be the fastest
option, but still ...

LP, Jure

On 24. 10. 2011 21:04, Brion Vibber wrote:

>
> I'd like for everybody who's working on MediaWiki on non-MySQL databases to
> make sure that the phpunit test suite can run on your favorite platform, so
> we can see about getting them set up in our regular reports on
> http://integration.mediawiki.org/ci/
>
> Green bars are your friend! :)
>
> -- brion
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Antoine Musso-3
On 25/10/11 16:24, Freako F. Freakolowsky wrote:
> I'll have a look(haven't poked the phpunit code for a while now) to make
> sure it's operational on Oracle backend.
>
> @Chad: if the issue is in the DB itself (i inderstand that running it
> can be somewhat of a pain) i could try to get you access to one of out
> sandbox instances for the purposes of CI. Might not be the fastest
> option, but still ...

Hello,

Looks like there is a free Oracle version named 'Express' which we might
use [1].  They are providing a Debian package [2] so we can get it
installed on Jenkins host easily, just need some configurationw hich can
probably be handled with puppet [3].


[1]
http://www.oracle.com/technetwork/database/express-edition/overview/index.html
[2] https://help.ubuntu.com/community/Oracle
[3] https://help.ubuntu.com/community/Oracle10g

--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Sumana Harihareswara-2
In reply to this post by Brion Vibber-3
Mark and I are interested in running a one-hour bug triage to discuss,
validate & prioritize MediaWiki bugs that affect Postgres, SQL Server,
Oracle, SQLite, MariaDB, and other non-MySQL databases. Ideally we'd
also come out with a first plan on improving database support.  If you
can make it tomorrow, the 28th, or Nov. 2nd or Nov. 3rd, please
indicate that on this poll.  If you can make tomorrow, please
additionally feel free to ping Mark and me directly and we'll try to
make up for the short notice!  :-)

http://www.doodle.com/wrwrixnreh3w8vby

Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation



On Mon, Oct 24, 2011 at 3:04 PM, Brion Vibber <[hidden email]> wrote:

> Hey all --
>
> I've got a stack of issues discussed during the last couple months'
> conferences and hackathons to raise, so there may be a few more manifestos
> on the way. But don't worry, this one will be short!
>
>
> I had a great chat at the New Orleans hackathon with D J Bauch who's been
> working on maintaining MediaWiki's MS SQL Server support, and also had a
> very useful email chat a couple weeks back with Freakalowsky who's put a lot
> of work into MediaWiki's Oracle support.
>
> Long story short: though traditionally MediaWiki developers have put very
> little work on our own into maintaining non-MySQL compatibility, there's
> still lots of folks interested in running on them... AND THEY ACTUALLY
> MOSTLY WORK!
>
> At this point I think it's a bit crazy of us to keep on marginalizing that
> code; some folks running their own instances will need or want or prefer (or
> be forced by office IT) to run on some "funny" database, and we shouldn't
> stand in their way. More importantly, keeping things working with multiple
> DB backends helps us to keep our code cleaner, and reduces our own hard
> dependencies on a particular product line.
>
>
> There are two main impediments to keeping code working on non-MySQL
> platforms:
> * lazy code breakages -- us MySQL-natives accidentally use MySQL-isms that
> break queries on other platforms
> * lazy schema updates -- us MySQL-natives add new schema updates into the
> system but only implement them for MySQL
>
> The first could often be helped simply by having automated testing run to
> make sure that relevant code paths get exercised. Often there's just a
> function that's used, or lazy use of LIMIT/OFFSET, or GROUP BY in a form
> that other databases are pickier about. Just flagging them from the testing
> can often be enough to make it easy to fix.
>
> The second is a bit harder, but again testing can help flag that something
> needs to be updated so it doesn't wait until too late for the next release,
> or something.
>
>
> I'd like for everybody who's working on MediaWiki on non-MySQL databases to
> make sure that the phpunit test suite can run on your favorite platform, so
> we can see about getting them set up in our regular reports on
> http://integration.mediawiki.org/ci/
>
> Green bars are your friend! :)
>
> -- brion
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Brion Vibber
In reply to this post by Antoine Musso-3
On Tue, Oct 25, 2011 at 8:17 AM, Antoine Musso <[hidden email]> wrote:

> Looks like there is a free Oracle version named 'Express' which we might
> use [1].  They are providing a Debian package [2] so we can get it
> installed on Jenkins host easily, just need some configurationw hich can
> probably be handled with puppet [3].
>
>
> [1]
>
> http://www.oracle.com/technetwork/database/express-edition/overview/index.html
> [2] https://help.ubuntu.com/community/Oracle
>

That debian repo only has the previous version (10g) though; the current 11g
only seems to be available for x86_64 as an RPM package, which allegedly
works on RHEL and OpenSuSE. Sigh...

I added a couple links to the current dl & documentation yesterday, but
haven't had a chance to test anything yet:
https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/Oracle

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Chad
On Tue, Oct 25, 2011 at 11:59 AM, Brion Vibber <[hidden email]> wrote:

> On Tue, Oct 25, 2011 at 8:17 AM, Antoine Musso <[hidden email]> wrote:
>
>> Looks like there is a free Oracle version named 'Express' which we might
>> use [1].  They are providing a Debian package [2] so we can get it
>> installed on Jenkins host easily, just need some configurationw hich can
>> probably be handled with puppet [3].
>>
>>
>> [1]
>>
>> http://www.oracle.com/technetwork/database/express-edition/overview/index.html
>> [2] https://help.ubuntu.com/community/Oracle
>>
>
> That debian repo only has the previous version (10g) though; the current 11g
> only seems to be available for x86_64 as an RPM package, which allegedly
> works on RHEL and OpenSuSE. Sigh...
>
> I added a couple links to the current dl & documentation yesterday, but
> haven't had a chance to test anything yet:
> https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/Oracle
>

Hmm, maybe we should set up a second box in addition to gallium for
this to act as the "database host" that has all the various DBMSes we
want to test.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Ryan Lane-2
> Hmm, maybe we should set up a second box in addition to gallium for
> this to act as the "database host" that has all the various DBMSes we
> want to test.
>

https://labsconsole.wikimedia.org/wiki/Main_Page

Just a suggestion ;)

- Ryan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Platonides
Ryan Lane wrote:
> https://labsconsole.wikimedia.org/wiki/Main_Page
>
> Just a suggestion ;)
>
> - Ryan

1) This is the first time it is mentioned in this mailing list.
1b) Not even mentioned in the Server Admin Log.
2) It has a funny concept of "you have an account"
3) Public IPs are private
4) Instances don't seem to be on wmf dns, despite statements of "ssh
<nameofinstance>" and "adding wmflabs domain in DNS"
5) Reading the git instructions make me feel sick
6) The RSA key (dc:e9:68:7b:99:1b:27:d0:f9:fd:ce:6a:2e:bf:92:e1?) is not
listed
7) Why is there a unicorn ?



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Bryan Tong Minh
On Tue, Oct 25, 2011 at 10:43 PM, Platonides <[hidden email]> wrote:
> 5) Reading the git instructions make me feel sick
Git instructions make people feel sick, well known fact.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Chad
In reply to this post by Platonides
On Tue, Oct 25, 2011 at 4:43 PM, Platonides <[hidden email]> wrote:
> 7) Why is there a unicorn ?
>

Because I suggested it for the Labs mascot, and nobody had
a better idea. True story.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki unit testing and non-MySQL databases

Daniel Friesen-4
In reply to this post by Bryan Tong Minh
On Tue, 25 Oct 2011 13:43:51 -0700, Bryan Tong Minh  
<[hidden email]> wrote:

> On Tue, Oct 25, 2011 at 10:43 PM, Platonides <[hidden email]>  
> wrote:
>> 5) Reading the git instructions make me feel sick
> Git instructions make people feel sick, well known fact.

Most git instructions don't include lines like:
git push ssh://<username>@gerrit.wikimedia.org:29418/operations/puppet  
HEAD:refs/for/test

This looks screwed up too:
git config --global user.name "<wiki-username>"

Last I checked user.name was intended to be a realname not some name  
linking.
My user.name is set to "Daniel Friesen" and there's no way in hell I'm  
changing it to "Dantman" which I DO expect to be my username on labs and  
whatnot.
There is likewise no way in hell I'm going to use  
`ssh://Daniel%[hidden email]`.

In fact this seams to be at odds with our own git migration notes. There  
seams to be notes on taking the USERINFO from svn usernames and converting  
them in the git conversion to realname and e-mail.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12