Hello, im erchache from EL (enciclopedia.us.es).
I want to update from 1.3.11 to 1.4.x but i have
duplicate entries on image table, and program doesnt
finish update process.
With this sentence i can see all duplicated entries:
SELECT img_name FROM image GROUP BY img_name HAVING
count(img_name) > 1;
But now i cant do a delete with a subquery to erase
duplicate entries less one.
+-----------------------------------------------------+-----------------+
| img_name
| count(img_name) |
+-----------------------------------------------------+-----------------+
| Ac.artemisephesus.jpg
| 2 |
This is a example. i want to delete all duplicate
entries and set it to 1.
Any can help me? I want to make it with sql sentences
to automate process.
Im waiting for your replies.
Thanks.
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es
http://bugzilla.wikipedia.org/show_bug.cgi?id=2259 asks to reenter two lines in User.php.
Users logging in with the temporary password can have their e-mail address confirmed implicitly, because they could have received the temp.passwd only via the stored e-mail address.
Thanks.
Is there any script (sql, PHP, Perl ..) that I could run (or write) that
could update my local table "old" that would replace the compressed old_text
fields by the uncompressed ones?
Indeed, the research project on which I work requires me to know the size of
each edit or comment in the table "old".
Kevin Carillo
Kevin Carillo wrote:
> I've successfully imported both cur and old tables.
> However, I am realizing that the text parts in the "old" table seem to be
in
> a compressed format.
> I do not know how Mediawiki is able to uncompress it and display it
> properly.
> but I'd like to have access the the column "old_text" through SQL
queries,
> how could I do that?
The old_flags field indicates the format of the old_text field: whether
it's compressed, whether it's a serialized object, etc.
The simplest thing to do is to work within the MediaWiki framework and
use Article::getRevisionText() on the retrieved database row: this will
run the appropriate decompression and will unserialize and extract text
from HistoryBlob and HistoryBlobStub object rows.
You might also check Erik Zachte's statistics scripts, a perl-based
package, to see how he's reading data.
After we've gotten MediaWiki 1.5 in place over the next couple weeks
we'll be providing a simple XML wrapper format for the backup dumps
which won't be nearly as messy to deal with. (This is the same format
used by Special:Export.) This will include an importer tool which could
be used to import all the data to a local database without compression.
-- brion vibber (brion @ <mailto:> pobox.com)
This appears to be increasingly common in recent weeks. We should
probably stop recently-created accounts from using user Javascript, in
the same way that was done with page moves for the Willy on Wheels
page-move vandalism outbreak.
Alternatively, it may be possible to make these kinds of attacks
significantly more difficult, by, for example, blacklisting the use of
certain functions in user JS?
-- Neil
Hi, there....
I've installed cur en.wikipedia from http://download.wikimedia.org/
but when I tried to load Categories, there was loaded just first text
"Without Subcategories " and "Articles in category"
For Example, for link: http://en.wikipedia.org/wiki/Category:Astronomy
was loaded just text before Subcategories.
What should I install for correct displaying this type of pages?
Thanks
Sergey
the initial copy was too slow and would've taken weeks to finish, so i've
restarted it at a slightly faster rate.
the remaining problem is that some images have files with names longer than
100 characters, which standard tar(1) can't represent (the maximum length
is 155 characters for directory + 100 for filename).
given the wide availability of GNU tar, i don't see a problem outputting
GNU-format tar files instead of POSIX ones, but i can't find any
documentation on their format. at least, the tar info files are not very
enlightening. so, in the interests of useful image dumps, does anyone know
where this is documented? :-)
thanks,
kate.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've asked this before, and got some vaguely positive answers, so I'll
try again...
Whould we add tables to the database that store the values of variables
passed to templates for each page? Like:
template_used : ID of page, ID of template page, unique ID
template_values : ID of template_used, variable name, value name
This would allow for searching the meta data that is stored in the
templates. My prime example would be the "Personendaten" (person data)
template on the German wikipedia. For "Albert Einstein", it looks like this:
{{Personendaten|
NAME=Einstein, Albert
|ALTERNATIVNAMEN=
|KURZBESCHREIBUNG=[[Physiker]]
|GEBURTSDATUM=[[14. März]] [[1879]]
|GEBURTSORT=[[Ulm]]
|STERBEDATUM=[[18. April]] [[1955]]
|STERBEORT=[[Princeton (New Jersey)|Princeton]], [[USA]]
}}
so one could generate a list of all people sorted by *last* name, with
key information like description, alternative names, time and place of
birth/death.
I thought of this again when I was contacted yesterday about a way to
improve wiktionary. I gathered that short of rewriting the whole
MediaWiki, one could (by default) change the edit function to display a
"real" input form, in contrast to the Big Text Box (tm) for a more
data-driven wiki site like wiktionary. The form info could then be
merged into a single text using a template, and taken apart again when
the page is edited further.
That would allow for changing the data display by merely editing the
template. Also, with the template variable/value mechanism described
above, (simple) search queries could be run through a special page, and
automatic processing of data sets (was:pages;-) would be possible/more
easy than now.
I would implement the database side, if there are no concernes about the
database getting Yet More Bloated, and MySQL Even More Sluggish (both
(TM) MediaWiki;-).
Magnus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFClbYeCZKBJbEFcz0RAla/AJ9fHOTj8j2+oZBOSYkr3cvrptnY0wCdHvWc
natYAuv9GpKDWg3ChiYtAT8=
=JJtR
-----END PGP SIGNATURE-----
Hello,
> Speaking of which, are we going to have a report about external storage in 1.4 from JeLuF or Domas?
I did merge my ExternalStorage support from HEAD to 1.4, and
JeLuF did nice work with specialized DB class, which allows
having archives (in 1.4) and all text (in 1.5). Currently we have
ability to simply move HistoryBlobs to external storage and
place ExternalStorage locators in main database. On live site
we started with building 3-node mysql cluster on top of some
apache hosts and JeLuF is already moving archive data
(concatenated gzips) to it.
Currently we haven't finalized the blob format in external storage,
as PHP archiving API isn't that handy, and serialized content sucks.
Anyway, idea of ExternalStore is really simple. You have a external
storage locator string either in 'text' or 'old' tables, with flags set to
'external', or in future we might be adding special location field to
revision table (or even make use of snowflake design ;-) The locator is like:
megastore://___put_anything_here___
When framework notices such content, it fires up
ExternalStorageMegastore.php (or any other, according to protocol),
and then storage class parses remaining part. Remaining part can specify
_anything_, and may be purely specific to ES class. In DB case, it specifies
MySQL cluster name and object id inside. In future it may specify content id
(in case of blob retrieval), etc. There is sample HTTP class as well, which
allows putting content on some external web server.
I would not be that surprised if someone would implement
ExternalStorageGmail ;-)
Anyway, keeping main relational databases as lean as
possible should be one of our primary concerns.
It doesn't matter that much in case of single server
setups though :)
Cheers,
Domas
Anarchopedia has the same problems, but only with sites with English interface.
I didn't see where to put a IP list of them? http://wiki.chongqed.org/
interface is not friendly: I have to explain every IP and in this
moment I have around 30 different IPs.
Any person interested in that problem can log in on
http://meta.anarchopedia.org, http://eng.anarchopedia.org and
http://hrv.anarchopedia.org. Good thing about Anarchopedia is that it
has small number of articles and that only three or four pages (which
don't exist) are the target. When the page is deleted, they are making
the page again with different IP so a lot of IPs can be recognized
(even it is possible that all of them exist in Wikimedia database).
See:
- http://meta.anarchopedia.org/index.php/Anarchopedia:Block_log
- http://eng.anarchopedia.org/index.php/Anarchopedia:Block_log
- http://hrv.anarchopedia.org/index.php/Anarchopedia:Block_log
If some developer is interested in that problem, (s)he can get dev
status and shell account on Anarchopedia.
(I am going to see what is going on with Infoshop OpenWiki.)
On 5/26/05, Anthere <anthere9(a)yahoo.com> wrote:
> Just read it on the french pump
>
> The Encyclopedia Libre has been heavily attacked by a spam bot 2 days
> ago. It spammed about 500 pages with a change of ip for each edit. It
> took them 1 full day to restore it all.
>
> As a consequence, log-in is now mandatory for contribution on EL.
>
> Ant
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l(a)Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>