Re: [Wikitech-l] Database API: Abstracting bitwise operations
bitNot, bitAnd, bitOr functions implemented and replaced hardcoded operators in SQL code with function calls. Did some testing, but i never trust my own testing so, please have click or two. l8r, Jure ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database API: Abstracting bitwise operations
Aryeh Gregor wrote:
> On Fri, Jun 12, 2009 at 10:02 AM, Leons
> Petrazickis wrote:
>> 1. Refactor the database to not use an integer as a bit field. Just
>> use four different boolean columns, which works well cross-database.
>
> In MySQL, four different boolean columns means four times the storage,
> as compared to one TINYINT used as a bitfield. So this isn't a good
> solution.
That's nonsense. We use a single TINYINT because it was introduced to
the schema as an unused boolean, and Brion later had the bright idea
of using it as a bitfield to expand its applications while avoiding
another schema change. It wouldn't make a significant difference to
database size if it were a text field with some complex ACL format,
like the old page.page_restrictions, and it's quite possible we would
have done that if the schema for it were designed from scratch.
However, we still want to avoid unnecessary schema changes to large
tables.
>> 2. Add a function to the Database API for each bit operator.
>>
>> $sql = $database->bitand('log_deleted', 1);
>>
>> 3. Add a function to the Database API to handle all the operators.
>>
>> $sql = $database->op('&', 'log_deleted', 1);
>> or
>> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>
> These would be the way to do it, I guess. We do something similar for
> things like conditionals already. I think 2 is preferable to 3,
> stylistically.
We also have the same scheme for string concatenation.
-- Tim Starling
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Licensing update: Final steps
2009/6/9 Platonides : > Sorry if it has already been discussed before but, why has the English > version to be included in the same page? > Isn't a link good enough? In the past years we've seen substantial semantic drift in the various localized/translated versions. Having the English version visible for consistent reference should help to avoid this. A two-column format should make it not-too-irritating. > We also need a technical way of flagging CC-BY-SA only content > (page_props?). No, we're not committing to any advanced tracking of GFDL; it's an obligation of re-users. (Which they should be able to meet by checking for attribution of single-licensed content.) -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikimedia, wikipedia and ipv6
Peter Gervai wrote: > Ehlo, > > I see that this topic has been popped up from time to time since 2004, > and that most of the misc servers have been already IPv6 enabled. I > have checked around whether google have any info on that, and found a > few (really few) mail on that, from the original 2004 test to a > comment from 2008 that squid and mediawiki is the problem, apart from > some smaller issues. (As a sidenote, google don't seem to find > anything on site:lists.wikimedia.org about "ipv6", interesting.) List archives are not searchable by google. > Now, squid fully supports IPv6 as of now (since 3.1), so I guess > that's check. (I didn't try it, though, but others seem to have.) > > MediaWiki, well, http://www.mediawiki.org/wiki/IPv6_support didn't > mention any outstanding problem and the linked bug is closed, so as > far as I'm observing (without actually testing it) it looks okay. > > The database structure may require some tuning as far as I see. Right? I don't think so. MediaWiki code may need some assumptions about it, though. > Apache handle it since eternity, php does I guess. > > Are there any further, non v6 compatible components in running a > wikipedia? If not, is there any outstanding proble which would make it > impossible to fire up a test interface on ipv6? > > I'd say to use a separate host, like en.ipv6.wikipedia.org, and not to > worry about the cache efficiency because I doubt that the ipv6 level > traffic would really measure up to the ipv4 one. At least it could be > properly measured, and decision should base on facts how to go on. > > Maybe there's a test host already on, but I wasn't able to find it, so > I guess nobody else can. ;-) I think this comment in the config summarises it: "no IPv6 support - 20051207" > Is there any further problem in this topic require solutions, or it > just didn't occur to anyone lately? > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database API: Abstracting bitwise operations
well anyway ... i'm having a working saturday tomorow, so just decide
what form do you want and i'll go trough the source tomorow and fix the
lot of it.
l8r
Leons Petrazickis wrote:
> Personally, I'd rather stay away from any regex-based SQL
> compatibility shims. I think they introduce tight-coupling to the
> system, and are by nature fragile.
>
> Handling bitwise operation in a generic way is quite doable. The
> Database API already has similar abstraction for other things. I'll be
> happy to check in the addition to the Database class tomorrow June
> 13th.
>
> Any more votes for which stylistic approach is preferable?
>
> 2. Add a function to the Database API for each bit operator.
>
> $sql = $database->bitand('log_deleted', 1);
> $sql = $database->bitor('log_deleted', 1);
> $sql = $database->bitxor('log_deleted', 1);
>
> 3. Add a function to the Database API to handle all the operators.
>
> $sql = $database->op('&', 'log_deleted', 1);
> $sql = $database->op('|', 'log_deleted', 1);
> $sql = $database->op('^', 'log_deleted', 1);
> or
> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
> $sql = $database->op(Database::BITOR, 'log_deleted', 1);
> $sql = $database->op(Database::BITXOR, 'log_deleted', 1);
>
> So far we've had one vote for option 1 and two votes for option 2.
>
> Regards,
>
> Leons Petrazickis
>
> On Fri, Jun 12, 2009 at 14:22, Freako F. Freakolowsky wrote:
>
>> but on the other hand ... if you would just make sure that the bitwise
>> comparison operation would always be in the "key" part of the array
>> makeList solution would work ...
>>
>> Freako F. Freakolowsky wrote:
>>
>>> I never said my solution was unbreakable, didn't even say it's good ...
>>> far from it ... I just said that the solution can be implemented there,
>>> but after your Sam&Max example i'm starting to doubt my way would work.
>>>
>>> So on that note i'm for what's behind door number 3 ... the second version
>>>
>>> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>>>
>>>
>>> Aryeh Gregor wrote:
>>> > On Fri, Jun 12, 2009 at 10:02 AM, Leons
>>> > Petrazickis wrote:
>>> >> 1. Refactor the database to not use an integer as a bit field. Just
>>> >> use four different boolean columns, which works well cross-database.
>>> >
>>> > In MySQL, four different boolean columns means four times the storage,
>>> > as compared to one TINYINT used as a bitfield. So this isn't a good
>>> > solution.
>>> >
>>> >> 2. Add a function to the Database API for each bit operator.
>>> >>
>>> >> $sql = $database->bitand('log_deleted', 1);
>>> >>
>>> >> 3. Add a function to the Database API to handle all the operators.
>>> >>
>>> >> $sql = $database->op('&', 'log_deleted', 1);
>>> >> or
>>> >> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>>> >
>>> > These would be the way to do it, I guess. We do something similar for
>>> > things like conditionals already. I think 2 is preferable to 3,
>>> > stylistically.
>>> >
>>> > On Fri, Jun 12, 2009 at 11:06 AM, Freako F.
>>> Freakolowsky wrote:
>>> >> Oracle abstraction solves this problem in makeList function ... the only
>>> >> weak point for this solution is if you write SQL statements manualy, if
>>> >> you use Database class functions to create the actual SQL statement this
>>> >> works and as i was told on #mediawiki manual sql creation should
>>> >> gradually be rooted out.
>>> >
>>> > This isn't a good solution:
>>> >
>>> > foreach ($a as $key => $value) {
>>> > if (strpos($key, ' & ') !== FALSE)
>>> > $a2[preg_replace('/(.*)\s&\s(.*)/', 'BITAND($1, $2)',
>>> > $key)] = $value;
>>> > elseif (strpos($key, ' | ') !== FALSE)
>>> > $a2[preg_replace('/(.*)\s|\s(.*)/', 'BITOR($1, $2)',
>>> > $key)] = $value;
>>> > elseif (!is_array($value)) {
>>> > if (strpos($value, ' = ') !== FALSE) {
>>> > if (strpos($value, ' & ') !== FALSE)
>>> > $a2[$key] =
>>> > preg_replace('/(.*)\s&\s(.*?)\s=\s(.*)/', 'BITAND($1, $2) = $3',
>>> > $value);
>>> > elseif (strpos($value, ' | ') !== FALSE)
>>> > $a2[$key] =
>>> > preg_replace('/(.*)\s|\s(.*?)\s=\s(.*)/', 'BITOR($1, $2) = $3',
>>> > $value);
>>> > else $a2[$key] = $value;
>>> > }
>>> > elseif (strpos($value, ' & ') !== FALSE)
>>> > $a2[$key] = preg_replace('/(.*)\s&\s(.*)/',
>>> > 'BITAND($1, $2)', $value);
>>> > elseif (strpos($value, ' | ') !== FALSE)
>>> > $a2[$key] = preg_replace('/(.*)\s|\s(.*)/',
>>> > 'BITOR($1, $2)', $value);
>>> > else
>>> > $a2[$key] = $value;
>>> > }
>>> >
>>> > It breaks on all sorts of possible input, like $dbr->select(
>>> > 'revision', '*', 'rev_deleted&1' ) or $dbr->update( 'user', array(
>>> > 'user
Re: [Wikitech-l] Database API: Abstracting bitwise operations
Personally, I'd rather stay away from any regex-based SQL
compatibility shims. I think they introduce tight-coupling to the
system, and are by nature fragile.
Handling bitwise operation in a generic way is quite doable. The
Database API already has similar abstraction for other things. I'll be
happy to check in the addition to the Database class tomorrow June
13th.
Any more votes for which stylistic approach is preferable?
2. Add a function to the Database API for each bit operator.
$sql = $database->bitand('log_deleted', 1);
$sql = $database->bitor('log_deleted', 1);
$sql = $database->bitxor('log_deleted', 1);
3. Add a function to the Database API to handle all the operators.
$sql = $database->op('&', 'log_deleted', 1);
$sql = $database->op('|', 'log_deleted', 1);
$sql = $database->op('^', 'log_deleted', 1);
or
$sql = $database->op(Database::BITAND, 'log_deleted', 1);
$sql = $database->op(Database::BITOR, 'log_deleted', 1);
$sql = $database->op(Database::BITXOR, 'log_deleted', 1);
So far we've had one vote for option 1 and two votes for option 2.
Regards,
Leons Petrazickis
On Fri, Jun 12, 2009 at 14:22, Freako F. Freakolowsky wrote:
> but on the other hand ... if you would just make sure that the bitwise
> comparison operation would always be in the "key" part of the array
> makeList solution would work ...
>
> Freako F. Freakolowsky wrote:
>> I never said my solution was unbreakable, didn't even say it's good ...
>> far from it ... I just said that the solution can be implemented there,
>> but after your Sam&Max example i'm starting to doubt my way would work.
>>
>> So on that note i'm for what's behind door number 3 ... the second version
>>
>> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>>
>>
>> Aryeh Gregor wrote:
>> > On Fri, Jun 12, 2009 at 10:02 AM, Leons
>> > Petrazickis wrote:
>> >> 1. Refactor the database to not use an integer as a bit field. Just
>> >> use four different boolean columns, which works well cross-database.
>> >
>> > In MySQL, four different boolean columns means four times the storage,
>> > as compared to one TINYINT used as a bitfield. So this isn't a good
>> > solution.
>> >
>> >> 2. Add a function to the Database API for each bit operator.
>> >>
>> >> $sql = $database->bitand('log_deleted', 1);
>> >>
>> >> 3. Add a function to the Database API to handle all the operators.
>> >>
>> >> $sql = $database->op('&', 'log_deleted', 1);
>> >> or
>> >> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>> >
>> > These would be the way to do it, I guess. We do something similar for
>> > things like conditionals already. I think 2 is preferable to 3,
>> > stylistically.
>> >
>> > On Fri, Jun 12, 2009 at 11:06 AM, Freako F.
>> Freakolowsky wrote:
>> >> Oracle abstraction solves this problem in makeList function ... the only
>> >> weak point for this solution is if you write SQL statements manualy, if
>> >> you use Database class functions to create the actual SQL statement this
>> >> works and as i was told on #mediawiki manual sql creation should
>> >> gradually be rooted out.
>> >
>> > This isn't a good solution:
>> >
>> > foreach ($a as $key => $value) {
>> > if (strpos($key, ' & ') !== FALSE)
>> > $a2[preg_replace('/(.*)\s&\s(.*)/', 'BITAND($1, $2)',
>> > $key)] = $value;
>> > elseif (strpos($key, ' | ') !== FALSE)
>> > $a2[preg_replace('/(.*)\s|\s(.*)/', 'BITOR($1, $2)',
>> > $key)] = $value;
>> > elseif (!is_array($value)) {
>> > if (strpos($value, ' = ') !== FALSE) {
>> > if (strpos($value, ' & ') !== FALSE)
>> > $a2[$key] =
>> > preg_replace('/(.*)\s&\s(.*?)\s=\s(.*)/', 'BITAND($1, $2) = $3',
>> > $value);
>> > elseif (strpos($value, ' | ') !== FALSE)
>> > $a2[$key] =
>> > preg_replace('/(.*)\s|\s(.*?)\s=\s(.*)/', 'BITOR($1, $2) = $3',
>> > $value);
>> > else $a2[$key] = $value;
>> > }
>> > elseif (strpos($value, ' & ') !== FALSE)
>> > $a2[$key] = preg_replace('/(.*)\s&\s(.*)/',
>> > 'BITAND($1, $2)', $value);
>> > elseif (strpos($value, ' | ') !== FALSE)
>> > $a2[$key] = preg_replace('/(.*)\s|\s(.*)/',
>> > 'BITOR($1, $2)', $value);
>> > else
>> > $a2[$key] = $value;
>> > }
>> >
>> > It breaks on all sorts of possible input, like $dbr->select(
>> > 'revision', '*', 'rev_deleted&1' ) or $dbr->update( 'user', array(
>> > 'user_name' => 'Sam & Max'), $where ), or any number of other things.
>> > Not actually tested, but it definitely breaks *somewhere*.
>> >
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> >
>>
>>
>> ___
Re: [Wikitech-l] Database API: Abstracting bitwise operations
On Fri, Jun 12, 2009 at 2:22 PM, Freako F. Freakolowsky wrote: > but on the other hand ... if you would just make sure that the bitwise > comparison operation would always be in the "key" part of the array > makeList solution would work ... Having that kind of silent and fragile rule in place isn't good, because it's counterintuitive. People aren't going to realize, they'll just assume bitwise operators work and use them everywhere. If you have an explicit method, then the existence of the method serves as documentation of the fact that you need to use it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database API: Abstracting bitwise operations
but on the other hand ... if you would just make sure that the bitwise
comparison operation would always be in the "key" part of the array
makeList solution would work ...
Freako F. Freakolowsky wrote:
> I never said my solution was unbreakable, didn't even say it's good ...
> far from it ... I just said that the solution can be implemented there,
> but after your Sam&Max example i'm starting to doubt my way would work.
>
> So on that note i'm for what's behind door number 3 ... the second version
>
> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>
>
> Aryeh Gregor wrote:
> > On Fri, Jun 12, 2009 at 10:02 AM, Leons
> > Petrazickis wrote:
> >> 1. Refactor the database to not use an integer as a bit field. Just
> >> use four different boolean columns, which works well cross-database.
> >
> > In MySQL, four different boolean columns means four times the storage,
> > as compared to one TINYINT used as a bitfield. So this isn't a good
> > solution.
> >
> >> 2. Add a function to the Database API for each bit operator.
> >>
> >> $sql = $database->bitand('log_deleted', 1);
> >>
> >> 3. Add a function to the Database API to handle all the operators.
> >>
> >> $sql = $database->op('&', 'log_deleted', 1);
> >> or
> >> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
> >
> > These would be the way to do it, I guess. We do something similar for
> > things like conditionals already. I think 2 is preferable to 3,
> > stylistically.
> >
> > On Fri, Jun 12, 2009 at 11:06 AM, Freako F.
> Freakolowsky wrote:
> >> Oracle abstraction solves this problem in makeList function ... the only
> >> weak point for this solution is if you write SQL statements manualy, if
> >> you use Database class functions to create the actual SQL statement this
> >> works and as i was told on #mediawiki manual sql creation should
> >> gradually be rooted out.
> >
> > This isn't a good solution:
> >
> > foreach ($a as $key => $value) {
> > if (strpos($key, ' & ') !== FALSE)
> > $a2[preg_replace('/(.*)\s&\s(.*)/', 'BITAND($1, $2)',
> > $key)] = $value;
> > elseif (strpos($key, ' | ') !== FALSE)
> > $a2[preg_replace('/(.*)\s|\s(.*)/', 'BITOR($1, $2)',
> > $key)] = $value;
> > elseif (!is_array($value)) {
> > if (strpos($value, ' = ') !== FALSE) {
> > if (strpos($value, ' & ') !== FALSE)
> > $a2[$key] =
> > preg_replace('/(.*)\s&\s(.*?)\s=\s(.*)/', 'BITAND($1, $2) = $3',
> > $value);
> > elseif (strpos($value, ' | ') !== FALSE)
> > $a2[$key] =
> > preg_replace('/(.*)\s|\s(.*?)\s=\s(.*)/', 'BITOR($1, $2) = $3',
> > $value);
> > else $a2[$key] = $value;
> > }
> > elseif (strpos($value, ' & ') !== FALSE)
> > $a2[$key] = preg_replace('/(.*)\s&\s(.*)/',
> > 'BITAND($1, $2)', $value);
> > elseif (strpos($value, ' | ') !== FALSE)
> > $a2[$key] = preg_replace('/(.*)\s|\s(.*)/',
> > 'BITOR($1, $2)', $value);
> > else
> > $a2[$key] = $value;
> > }
> >
> > It breaks on all sorts of possible input, like $dbr->select(
> > 'revision', '*', 'rev_deleted&1' ) or $dbr->update( 'user', array(
> > 'user_name' => 'Sam & Max'), $where ), or any number of other things.
> > Not actually tested, but it definitely breaks *somewhere*.
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database API: Abstracting bitwise operations
I never said my solution was unbreakable, didn't even say it's good ...
far from it ... I just said that the solution can be implemented there,
but after your Sam&Max example i'm starting to doubt my way would work.
So on that note i'm for what's behind door number 3 ... the second version
$sql = $database->op(Database::BITAND, 'log_deleted', 1);
Aryeh Gregor wrote:
> On Fri, Jun 12, 2009 at 10:02 AM, Leons
> Petrazickis wrote:
>> 1. Refactor the database to not use an integer as a bit field. Just
>> use four different boolean columns, which works well cross-database.
>
> In MySQL, four different boolean columns means four times the storage,
> as compared to one TINYINT used as a bitfield. So this isn't a good
> solution.
>
>> 2. Add a function to the Database API for each bit operator.
>>
>> $sql = $database->bitand('log_deleted', 1);
>>
>> 3. Add a function to the Database API to handle all the operators.
>>
>> $sql = $database->op('&', 'log_deleted', 1);
>> or
>> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>
> These would be the way to do it, I guess. We do something similar for
> things like conditionals already. I think 2 is preferable to 3,
> stylistically.
>
> On Fri, Jun 12, 2009 at 11:06 AM, Freako F.
Freakolowsky wrote:
>> Oracle abstraction solves this problem in makeList function ... the only
>> weak point for this solution is if you write SQL statements manualy, if
>> you use Database class functions to create the actual SQL statement this
>> works and as i was told on #mediawiki manual sql creation should
>> gradually be rooted out.
>
> This isn't a good solution:
>
> foreach ($a as $key => $value) {
> if (strpos($key, ' & ') !== FALSE)
> $a2[preg_replace('/(.*)\s&\s(.*)/', 'BITAND($1, $2)',
> $key)] = $value;
> elseif (strpos($key, ' | ') !== FALSE)
> $a2[preg_replace('/(.*)\s|\s(.*)/', 'BITOR($1, $2)',
> $key)] = $value;
> elseif (!is_array($value)) {
> if (strpos($value, ' = ') !== FALSE) {
> if (strpos($value, ' & ') !== FALSE)
> $a2[$key] =
> preg_replace('/(.*)\s&\s(.*?)\s=\s(.*)/', 'BITAND($1, $2) = $3',
> $value);
> elseif (strpos($value, ' | ') !== FALSE)
> $a2[$key] =
> preg_replace('/(.*)\s|\s(.*?)\s=\s(.*)/', 'BITOR($1, $2) = $3',
> $value);
> else $a2[$key] = $value;
> }
> elseif (strpos($value, ' & ') !== FALSE)
> $a2[$key] = preg_replace('/(.*)\s&\s(.*)/',
> 'BITAND($1, $2)', $value);
> elseif (strpos($value, ' | ') !== FALSE)
> $a2[$key] = preg_replace('/(.*)\s|\s(.*)/',
> 'BITOR($1, $2)', $value);
> else
> $a2[$key] = $value;
> }
>
> It breaks on all sorts of possible input, like $dbr->select(
> 'revision', '*', 'rev_deleted&1' ) or $dbr->update( 'user', array(
> 'user_name' => 'Sam & Max'), $where ), or any number of other things.
> Not actually tested, but it definitely breaks *somewhere*.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database API: Abstracting bitwise operations
On Fri, Jun 12, 2009 at 10:02 AM, Leons
Petrazickis wrote:
> 1. Refactor the database to not use an integer as a bit field. Just
> use four different boolean columns, which works well cross-database.
In MySQL, four different boolean columns means four times the storage,
as compared to one TINYINT used as a bitfield. So this isn't a good
solution.
> 2. Add a function to the Database API for each bit operator.
>
> $sql = $database->bitand('log_deleted', 1);
>
> 3. Add a function to the Database API to handle all the operators.
>
> $sql = $database->op('&', 'log_deleted', 1);
> or
> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
These would be the way to do it, I guess. We do something similar for
things like conditionals already. I think 2 is preferable to 3,
stylistically.
On Fri, Jun 12, 2009 at 11:06 AM, Freako F. Freakolowsky wrote:
> Oracle abstraction solves this problem in makeList function ... the only
> weak point for this solution is if you write SQL statements manualy, if
> you use Database class functions to create the actual SQL statement this
> works and as i was told on #mediawiki manual sql creation should
> gradually be rooted out.
This isn't a good solution:
foreach ($a as $key => $value) {
if (strpos($key, ' & ') !== FALSE)
$a2[preg_replace('/(.*)\s&\s(.*)/', 'BITAND($1, $2)',
$key)] = $value;
elseif (strpos($key, ' | ') !== FALSE)
$a2[preg_replace('/(.*)\s|\s(.*)/', 'BITOR($1, $2)',
$key)] = $value;
elseif (!is_array($value)) {
if (strpos($value, ' = ') !== FALSE) {
if (strpos($value, ' & ') !== FALSE)
$a2[$key] =
preg_replace('/(.*)\s&\s(.*?)\s=\s(.*)/', 'BITAND($1, $2) = $3',
$value);
elseif (strpos($value, ' | ') !== FALSE)
$a2[$key] =
preg_replace('/(.*)\s|\s(.*?)\s=\s(.*)/', 'BITOR($1, $2) = $3',
$value);
else $a2[$key] = $value;
}
elseif (strpos($value, ' & ') !== FALSE)
$a2[$key] = preg_replace('/(.*)\s&\s(.*)/',
'BITAND($1, $2)', $value);
elseif (strpos($value, ' | ') !== FALSE)
$a2[$key] = preg_replace('/(.*)\s|\s(.*)/',
'BITOR($1, $2)', $value);
else
$a2[$key] = $value;
}
It breaks on all sorts of possible input, like $dbr->select(
'revision', '*', 'rev_deleted&1' ) or $dbr->update( 'user', array(
'user_name' => 'Sam & Max'), $where ), or any number of other things.
Not actually tested, but it definitely breaks *somewhere*.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database API: Abstracting bitwise operations
This didn't even come up on my radar as I began working on integrating
the 1.15.0 changes into the Microsoft SQL Server version. Here's why:
It didn't break anything. The only noticeable database-related
breakage recently has been with the Special:RecentChanges and
Special:RecentChangesLinked pages, which use LIMIT and ORDER BY
together with UNION in a way not supported by SQL Server. So, you can
update your summary of the bitwise operator syntax in different
databases to reflect that.
MySQL, PostgeSQL, SQL Server
log_deleted & 1
On Fri, Jun 12, 2009 at 10:06 AM, Freako F. Freakolowsky wrote:
> Oracle abstraction solves this problem in makeList function ... the only
> weak point for this solution is if you write SQL statements manualy, if
> you use Database class functions to create the actual SQL statement this
> works and as i was told on #mediawiki manual sql creation should
> gradually be rooted out.
>
>
> Leons Petrazickis wrote:
>> The 1.15 release of MediaWiki introduced some hardcoded bitwise
>> operators to the core SQL. They were added to operate on the
>> log_deleted column in the logging table by, I think, aaron. This is
>> because the log_deleted column now has multiple states.
>>
>> Unfortunately, bitwise operators have different syntax in different
>> databases.
>>
>> MySQL, PostgreSQL:
>> log_deleted & 1
>>
>> DB2, Oracle:
>> BITAND(log_deleted, 1)
>>
>>
>> I think there are three options to make it compatible:
>>
>> 1. Refactor the database to not use an integer as a bit field. Just
>> use four different boolean columns, which works well cross-database.
>>
>> 2. Add a function to the Database API for each bit operator.
>>
>> $sql = $database->bitand('log_deleted', 1);
>>
>> 3. Add a function to the Database API to handle all the operators.
>>
>> $sql = $database->op('&', 'log_deleted', 1);
>> or
>> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>>
>>
>> My preference is for option 1 or 3. Thoughts?
>>
>> Regards,
>>
>> Leons Petrazickis
>> http://lpetr.org/blog/
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database API: Abstracting bitwise operations
Oracle abstraction solves this problem in makeList function ... the only
weak point for this solution is if you write SQL statements manualy, if
you use Database class functions to create the actual SQL statement this
works and as i was told on #mediawiki manual sql creation should
gradually be rooted out.
Leons Petrazickis wrote:
> The 1.15 release of MediaWiki introduced some hardcoded bitwise
> operators to the core SQL. They were added to operate on the
> log_deleted column in the logging table by, I think, aaron. This is
> because the log_deleted column now has multiple states.
>
> Unfortunately, bitwise operators have different syntax in different databases.
>
> MySQL, PostgreSQL:
> log_deleted & 1
>
> DB2, Oracle:
> BITAND(log_deleted, 1)
>
>
> I think there are three options to make it compatible:
>
> 1. Refactor the database to not use an integer as a bit field. Just
> use four different boolean columns, which works well cross-database.
>
> 2. Add a function to the Database API for each bit operator.
>
> $sql = $database->bitand('log_deleted', 1);
>
> 3. Add a function to the Database API to handle all the operators.
>
> $sql = $database->op('&', 'log_deleted', 1);
> or
> $sql = $database->op(Database::BITAND, 'log_deleted', 1);
>
>
> My preference is for option 1 or 3. Thoughts?
>
> Regards,
>
> Leons Petrazickis
> http://lpetr.org/blog/
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Database API: Abstracting bitwise operations
The 1.15 release of MediaWiki introduced some hardcoded bitwise
operators to the core SQL. They were added to operate on the
log_deleted column in the logging table by, I think, aaron. This is
because the log_deleted column now has multiple states.
Unfortunately, bitwise operators have different syntax in different databases.
MySQL, PostgreSQL:
log_deleted & 1
DB2, Oracle:
BITAND(log_deleted, 1)
I think there are three options to make it compatible:
1. Refactor the database to not use an integer as a bit field. Just
use four different boolean columns, which works well cross-database.
2. Add a function to the Database API for each bit operator.
$sql = $database->bitand('log_deleted', 1);
3. Add a function to the Database API to handle all the operators.
$sql = $database->op('&', 'log_deleted', 1);
or
$sql = $database->op(Database::BITAND, 'log_deleted', 1);
My preference is for option 1 or 3. Thoughts?
Regards,
Leons Petrazickis
http://lpetr.org/blog/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikimedia, wikipedia and ipv6
On Fri, Jun 12, 2009 at 13:55, Aryeh Gregor wrote: > This might be useful, although most of the info is probably outdated: > http://wikitech.wikimedia.org/view/Special:Search?search=ipv6&go=Go Yep, including the dead labs link. But it mentioned LVS [ipvs], dunno whether we use it or not, but it supports ipv6 either. ;-) g ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikimedia, wikipedia and ipv6
On Fri, Jun 12, 2009 at 6:40 AM, Peter Gervai wrote: > I see that this topic has been popped up from time to time since 2004, > and that most of the misc servers have been already IPv6 enabled. I > have checked around whether google have any info on that, and found a > few (really few) mail on that, from the original 2004 test to a > comment from 2008 that squid and mediawiki is the problem, apart from > some smaller issues. (As a sidenote, google don't seem to find > anything on site:lists.wikimedia.org about "ipv6", interesting.) This might be useful, although most of the info is probably outdated: http://wikitech.wikimedia.org/view/Special:Search?search=ipv6&go=Go ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] wikimedia, wikipedia and ipv6
Ehlo, I see that this topic has been popped up from time to time since 2004, and that most of the misc servers have been already IPv6 enabled. I have checked around whether google have any info on that, and found a few (really few) mail on that, from the original 2004 test to a comment from 2008 that squid and mediawiki is the problem, apart from some smaller issues. (As a sidenote, google don't seem to find anything on site:lists.wikimedia.org about "ipv6", interesting.) Now, squid fully supports IPv6 as of now (since 3.1), so I guess that's check. (I didn't try it, though, but others seem to have.) MediaWiki, well, http://www.mediawiki.org/wiki/IPv6_support didn't mention any outstanding problem and the linked bug is closed, so as far as I'm observing (without actually testing it) it looks okay. The database structure may require some tuning as far as I see. Right? Apache handle it since eternity, php does I guess. Are there any further, non v6 compatible components in running a wikipedia? If not, is there any outstanding proble which would make it impossible to fire up a test interface on ipv6? I'd say to use a separate host, like en.ipv6.wikipedia.org, and not to worry about the cache efficiency because I doubt that the ipv6 level traffic would really measure up to the ipv4 one. At least it could be properly measured, and decision should base on facts how to go on. Maybe there's a test host already on, but I wasn't able to find it, so I guess nobody else can. ;-) Is there any further problem in this topic require solutions, or it just didn't occur to anyone lately? -- byte-byte, grin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
