Roan Kattouw wrote:
> Just some basic comments, I'm sure Brion has more.
You should probably send them to CodeReview these days.
>> +/**
>> + * This represents a column in a DB2 database
>> + * @ingroup Database
>> + */
>> +class IBM_DB2Field {
[...]
>>
> Why do you need this? The other Database backends don't have it.
Actually SQLite is going to have one after I commit my working copy. And
MySQL has had one for a while.
>> + /**
>> + * USE INDEX clause
>> + * DB2 doesn't have them and returns ""
>> + * @param sting $index
>> + */
>> + public function useIndexClause( $index ) {
>> + return "";
>> + }
>>
> What do you mean DB2 "doesn't have them"? FORCE INDEX isn't supported in
> DB2? Then unless its index choosing algorithm is extremely good, it
> won't be able to run certain queries with satisfactory efficiency.
SQLite doesn't have them either. It's not an issue.
>> +-- should be replaced with OmniFind, Contains(), etc
>> +CREATE TABLE searchindex (
>> + si_page int NOT NULL,
>> + si_title varchar(255) NOT NULL default '',
>> + si_text clob NOT NULL
>> +);
>>
> Don't you need some index on this table to enable efficient searching?
SQLite doesn't have a built-in full-text search engine either, and
PostgreSQL only has one starting in 8.3. The schema I'll use for SQLite is
pretty much the same. It keeps the scripts happy. They'll use
SearchEngineDummy by default and so the table won't be populated. Lucene
can be used instead.
-- Tim Starling
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
