May 2005 - Development - lists.drupal.org

Re: [drupal-devel] [drupal-docs] creating drupal-doc teams
by Charlie Lowe 20 May '05

20 May '05

You are definitely right. I should clarify. Of course we can have more than two people working on each of these projects. But I'd like to have two people in charge of the project group. Perhaps they should be called "team leaders" :) Andrew Hoppin wrote: > Charlie, I'd love to help on marketing materials, though the next > couple of weeks are bad for me, and I'd love the team to be larger than > 2 if I were 1! :) > > Andrew > > **************************************** > Andrew Hoppin > 1.212.464.7665 (m) > andrew(a)civicspacelabs.org > **************************************** > > > On May 19, 2005, at 3:02 PM, Charlie Lowe wrote: > > >>Currently, it seems we have lots of interest in taking Drupal >>documentation in new and interesting directions. To facilitate this, >>I'd >>like to see if we can't form some documentation teams. Much like I >>asked >>if Djun and Bryan would be in charge of reorganizing the About section >>of the handbook, I'd like us to form other two person teams for any >>major area that we have expressed interest in developing. >> >>Here are just a few examples of some areas I could imagine >> >>Documentation teams for >> >>* Restructuring/reorganizing each of the new handbook sections as >>defined on the V2 page: >> >>http://drupal.org/handbook/v2 >> >>For example, the About the handbook section. We need a couple of people >>to be in charge of our authoring guidelines and best practices for >>creating Drupal handbook documentation. >> >>(Anisa spearheaded the style guide revision; perhaps we could coax her >>and one other person to handle the About the handbook section?) >> >>* Best practices for configuring and building Druapl sites >> >>(Roland has already volunteered for this one :) Is there another?) >> >>* Initiatives for improving the collaborative book and other >>technological solutions to improve Drupal documentation usability, >>integration, and creation. >> >>(Djun has already been working on this. Perhaps he'd like to be one of >>the team members. We'd only need one other volunteer then.) >> >>* Marketing materials >> >>(Andre? You seem to have lots of marketing ideas :) >> >>* Etc. >> >>The documentation team would be responsible for most decisions >>regarding >>their project (in some cases there might be some overlap between other >>documentation teams, so they'd have to coordinate). Initially, I would >>hope that each documentation team would run a proposal by the >>drupal-docs list so that all of us could offer feedback in the >>construction of their individual project so that a good compromise of >>the important opposing interests (if any) can be reached. >> >>Otherwise, let us know when new documentation is posted (maybe this >>will >>be automated) so that we can offer feedback and suggestions. Or when >>the >>documentation team members are having trouble solving an issue between >>themselves, contact the list for assistance in resolution. >> >>In the case of any who volunteer for restructuring/revising the >>handbook >>sections, if they would like, they could also continue on as the >>offical >>book maintainers for those new books. >> >>If anyone has ideas for other documentation team areas, please respond >>to this post via the drupal-docs list. I've mentioned a few people >>here, >>but I'm sure there are a lot more. If anyone would like to volunteer to >>be a documentation team member for a specific project, feel free to >>post >>to the drupal-docs list or contact me privately. >> >>Once the documentation teams have been created, I'll create a page in >>the About handbook section so that people know who's in charge of >>individual projects. >> >>I hope this works well for everyone. Putting people in charge of >>specific areas seems to me the best way for us to get the things we >>want >>accomplished. >> >>Charlie >>-- >>[ drupal-docs | http://lists.drupal.org/listinfo/drupal-docs ] > >

1 0

[drupal-devel] Bug#301394: marked as done ([INTL:pt_PT] Portuguese translation for drupal package)
by owner＠bugs.debian.org 19 May '05

19 May '05

Your message dated Thu, 19 May 2005 17:17:35 -0400 with message-id <E1DYsOd-0007wa-00(a)newraff.debian.org> and subject line Bug#301394: fixed in drupal 4.5.2-4 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 25 Mar 2005 16:22:49 +0000 >From elmig(a)debianpt.org Fri Mar 25 08:22:48 2005 Return-path: <elmig(a)debianpt.org> Received: from bl4-107-112.dsl.telepac.pt (elmig.net.dhis.org) [81.193.107.112] by spohr.debian.org with smtp (Exim 3.35 1 (Debian)) id 1DEraC-0008JC-00; Fri, 25 Mar 2005 08:22:48 -0800 Received: (qmail 2832 invoked from network); 25 Mar 2005 16:22:49 -0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by 10.0.0.1 with SMTP; 25 Mar 2005 16:22:49 -0000 Message-ID: <42443A82.8050407(a)debianpt.org> Date: Fri, 25 Mar 2005 16:21:22 +0000 From: Miguel Figueiredo <elmig(a)debianpt.org> Organization: DebianPT.org User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: submit(a)bugs.debian.org Subject: [INTL:pt_PT] Portuguese translation for drupal package Content-Type: multipart/mixed; boundary="------------000005010305060308080807" Delivered-To: submit(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-2.3 required=4.0 tests=BAYES_44,HAS_PACKAGE, RCVD_IN_DSBL,REMOVE_REMOVAL_NEAR autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: This is a multi-part message in MIME format. --------------000005010305060308080807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Package: drupal Version: 4.5.2 Severity: wishlist Tag: patch, l10n Here goes a Portuguese translation for the Drupal package. Feel free to use it. Best Regards, Miguel Figueiredo http://www.debianPT.org --------------000005010305060308080807 Content-Type: text/x-gettext-translation; name="pt.po" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="pt.po" # Portuguese translation od Drupal's debconf messages. # 2005, Miguel Figueiredo <elmig(a)debianpt.org> msgid "" msgstr "" "Project-Id-Version: drupal 4.5.2-1\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2004-03-13 19:13+0100\n" "PO-Revision-Date: 2005-03-25 13:54+0000\n" "Last-Translator: Miguel Figueiredo <elmig(a)debianpt.org>>\n" "Language-Team: Portuguese <traduz(a)debianpt.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates.master:4 msgid "Automatically create Drupal database?" msgstr "Criar automaticamente a base de dados do Drupal?" #. Type: boolean #. Description #: ../templates.master:4 msgid "" "Drupal needs access to a database, along with initialized data structures in " "order to function properly. This can be created automatically by this " "package, for MySQL or PostgreSQL databases." msgstr "" "O Drupal necessita de aceder a uma base de dados, assim como a estruturas " "de dados inicializadas de modo a funcionar correctamente. Isto pode ser " "criado automaticamente por este pacote, para bases de dados MySQL ou " "PostgreSQL." #. Type: boolean #. Description #: ../templates.master:4 msgid "" "Automatically creating the database does not make sense if a Drupal database " "already exists or if no database server has been setup when Drupal is " "installed." msgstr "" "Criar automaticamente a base de dados não faz sentido se já existir uma " "base de dados do Drupal ou se não foi preparado nenhum servidor de bases " "de dados quando o Drupal foi instalado." #. Type: boolean #. Description #: ../templates.master:16 msgid "Run database update script?" msgstr "Correr o script de actualização da base de dados?" #. Type: boolean #. Description #: ../templates.master:16 msgid "" "If you are upgrading Drupal from an older upstream version, the database " "structure needs to be updated. This package can perform this task " "automatically." msgstr "" "Se estiver a actualizar o Drupal a partir de uma versão upstream mais " "antiga, a estrutura da base de dados necessita ser actualizada. Este " "pacote pode executar essa tarefa automaticamente." #. Type: boolean #. Description #: ../templates.master:16 msgid "The database will be backed up to prevent data loss." msgstr "A base de dados será salvaguardada para prevenir a perda de dados." #. Type: select #. Description #: ../templates.master:27 msgid "Database engine to be used with Drupal" msgstr "Motor da base de dados para ser utilizado com o Drupal" #. Type: string #. Description #: ../templates.master:32 msgid "Database server for Drupal's database" msgstr "Servidor de base de dados para a base de dados do Drupal" #. Type: string #. Description #: ../templates.master:37 msgid "Database server administrator user name on host ${host}" msgstr "Nome de utilizador do administrador do servidor de bases de dados " "no host ${host}" #. Type: password #. Description #: ../templates.master:42 msgid "Password for database server administrator ${user} on host ${host}" msgstr "Password do administrador ${user} do servidor de bases de dados " "no host ${host}" #. Type: password #. Description #: ../templates.master:42 msgid "The answer will not be stored anywhere permanently." msgstr "A resposta não será guardada em qualquer local de forma permanente." #. Type: string #. Description #: ../templates.master:48 msgid "Drupal database owner username" msgstr "Nome de utilizador do dono da base de dados do Drupal" #. Type: string #. Description #: ../templates.master:48 msgid "This username will be used by Drupal to connect to the database server." msgstr "Este nome de utilizador será utilizado pelo Drupal para se ligar " "ao servidor de bases de dados." #. Type: password #. Description #: ../templates.master:54 msgid "Drupal database owner password" msgstr "Password do dono da base de dados do Drupal" #. Type: password #. Description #: ../templates.master:54 msgid "If no password is specified here, a random password will be generated." msgstr "Se nenhuma password for especificada aqui, será gerada uma password " "aleatória." #. Type: string #. Description #: ../templates.master:61 msgid "Drupal database name" msgstr "Nome da base de dados do Drupal" #. Type: boolean #. Description #: ../templates.master:66 msgid "Remove Drupal database when the package is removed?" msgstr "Remover a base de dados do Drupal quando o pacote for removido?" #. Type: boolean #. Description #: ../templates.master:71 msgid "Remove former database backups when the package is removed?" msgstr "Remover backups antigos da base de dados quando o pacote for removido?" #. Type: boolean #. Description #: ../templates.master:71 msgid "" "These backups are stored in /var/lib/drupal/backups. This will not remove " "the current database from the DBMS." msgstr "" "Estes backups são guardados em /var/lib/drupal/backups. Isto não irá " "remover a base de dados actual do SGDB." #. Type: multiselect #. Description #: ../templates.master:79 msgid "Web server(s) that should be configured automatically" msgstr "Servidor(es) web que devem ser configurados automaticamente" #. Type: note #. Description #: ../templates.master:83 msgid "User creation failed" msgstr "A criação do utilizador falhou" #. Type: note #. Description #: ../templates.master:90 msgid "Attempt to modify config file ${conffile} failed" msgstr "Falhou a tentativa de modificar o ficheiro de configuração ${conffile}" #. Type: note #. Description #: ../templates.master:97 msgid "Database creation failed" msgstr "Falhou a criação da base de dados" #. Type: note #. Description #: ../templates.master:104 msgid "Database initialization failed" msgstr "Falhou a inicialização da base de dados" #. Type: note #. Description #: ../templates.master:111 msgid "Automatic database update failed" msgstr "Falhou a actualização automática da base de dados" #. Type: note #. Description #: ../templates.master:111 msgid "The automatic update script failed to update the database." msgstr "O script de actualização automática falhou a actualização da base de dados." #. Type: note #. Description #: ../templates.master:120 msgid "Automatic update script can not be run" msgstr "O script de actualização automática não pode ser corrido" #. Type: note #. Description #: ../templates.master:120 msgid "" "Configuration files of a Drupal package ${oldversion} have been found, but " "the package itself has been removed. Therefore, it is not possible to run " "the automatic update script." msgstr "" "Foram encontrados ficheiros de configuração de um pacote " "Drupal ${oldversion}, mas o pacote em si foi removido. Por isso, " "não é possível correr o script de actualização automática." #. Type: note #. Description #: ../templates.master:120 msgid "" "Please run it by hand after the package has been successfully installed. " "Either point your web browser to ${site_root}/update.php or run /usr/share/" "drupal/scripts/debian-update.php from a shell." msgstr "" "Por favor corra-o manualmente após o pacote ter sido instalado com " "sucesso. Ou aponte o seu browser web para ${site_root}/update.php ou " "corra a partir da shell /usr/share/drupal/scripts/debian-update.php." #. Type: note #. Description #: ../templates.master:132 msgid "Database removal failed" msgstr "Falhou a remoção da base de dados" #. Type: note #. Description #: ../templates.master:132 msgid "Script output:" msgstr "Saída do script:" #. Type: note #. Description #: ../templates.master:132 msgid "${result}" msgstr "${result}" --------------000005010305060308080807-- --------------------------------------- Received: (at 301394-close) by bugs.debian.org; 19 May 2005 21:20:27 +0000 >From katie(a)ftp-master.debian.org Thu May 19 14:20:26 2005 Return-path: <katie(a)ftp-master.debian.org> Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DYsRO-0005rL-00; Thu, 19 May 2005 14:20:26 -0700 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DYsOd-0007wa-00; Thu, 19 May 2005 17:17:35 -0400 From: Hilko Bengen <bengen(a)debian.org> To: 301394-close(a)bugs.debian.org X-Katie: $Revision: 1.55 $ Subject: Bug#301394: fixed in drupal 4.5.2-4 Message-Id: <E1DYsOd-0007wa-00(a)newraff.debian.org> Sender: Archive Administrator <katie(a)ftp-master.debian.org> Date: Thu, 19 May 2005 17:17:35 -0400 Delivered-To: 301394-close(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Source: drupal Source-Version: 4.5.2-4 We believe that the bug you reported is fixed in the latest version of drupal, which is due to be installed in the Debian FTP archive: drupal_4.5.2-4.diff.gz to pool/main/d/drupal/drupal_4.5.2-4.diff.gz drupal_4.5.2-4.dsc to pool/main/d/drupal/drupal_4.5.2-4.dsc drupal_4.5.2-4_all.deb to pool/main/d/drupal/drupal_4.5.2-4_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 301394(a)bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Hilko Bengen <bengen(a)debian.org> (supplier of updated drupal package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster(a)debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.7 Date: Thu, 19 May 2005 21:23:27 +0200 Source: drupal Binary: drupal Architecture: source all Version: 4.5.2-4 Distribution: unstable Urgency: low Maintainer: Hilko Bengen <bengen(a)debian.org> Changed-By: Hilko Bengen <bengen(a)debian.org> Description: drupal - fully-featured content management/discussion engine Closes: 301394 301946 306997 Changes: drupal (4.5.2-4) unstable; urgency=low . * [Miguel Figueiredo <elmig(a)debianpt.org>] Added Portuguese translation (Closes: #301394) * [Valentina Commissari <ayor(a)quaqua.net>] Added Italian translation (Closes: #301946) * [Gleydson Mazioli da Silva <gleydson(a)debian.org>] Updated Brazilian Portuguese translation. * Fixed typo in package description (Closes: #306997) Files: f36a5fd78d26ebb6c9935d9569cc5130 609 web extra drupal_4.5.2-4.dsc 8ec0c830ae5fa35def8748bc0c215704 38367 web extra drupal_4.5.2-4.diff.gz 30333b315df4c7e169d2ea527b01a41c 484812 web extra drupal_4.5.2-4_all.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCjP3WUCgnLz/SlGgRArERAJ9ncqDeD/Rk2jjYdcTZYHlyhmO/9QCfW/Gn Y4dwFZSdXMrCAy7xoYrVO0Y= =71Pz -----END PGP SIGNATURE-----

1 0

[drupal-devel] Bug#306997: marked as done (drupal: Typo in package description.)
by owner＠bugs.debian.org 19 May '05

19 May '05

Your message dated Thu, 19 May 2005 17:17:35 -0400 with message-id <E1DYsOd-0007we-00(a)newraff.debian.org> and subject line Bug#306997: fixed in drupal 4.5.2-4 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 30 Apr 2005 01:01:24 +0000 >From cafuego(a)mail.cc.com.au Fri Apr 29 18:01:24 2005 Return-path: <cafuego(a)mail.cc.com.au> Received: from mail.cc.com.au [202.125.40.176] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DRgMG-0004mv-00; Fri, 29 Apr 2005 18:01:24 -0700 Received: by mail.cc.com.au (Postfix, from userid 1000) id E976680C003; Sat, 30 Apr 2005 11:01:21 +1000 (EST) Date: Sat, 30 Apr 2005 11:01:21 +1000 From: Peter Lieverdink <debian-bugs(a)cafuego.net> To: Debian Bug Tracking System <submit(a)bugs.debian.org> Subject: drupal: Typo in package description. Message-ID: <20050430010116.GA27663(a)mail.cc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Silly-Header: I have edited my /etc/reportbug.conf X-Reportbug-Version: 3.8 User-Agent: Mutt/1.5.9i Delivered-To: submit(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: drupal Version: 4.5.2-3 Severity: minor Description: fully-featured content management/discussion engine Drupal is a dynamic web site platform which allows an individual or community of users to publish, manage and organize a variety of content, Drupal integrates many popular features of content management systems, weblogs, collaborative tools and discussion-based community software into one easy-to-use package. . More informatiion about is available at http://www.drupal.org Note the duplicate 'i' in informatiion. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages drupal depends on: ii apache 1.3.33-4 versatile, high-performance HTTP s ii apache2-mpm-prefork [apache2 2.0.53-5 traditional model for Apache2 ii debconf 1.4.30.13 Debian configuration management sy pn makepasswd Not found. ii mysql-client 4.0.24-5 mysql database client binaries ii php4-cgi 4:4.3.10-12 server-side, HTML-embedded scripti ii php4-mysql 4:4.3.10-12 MySQL module for php4 ii php4-pear 4:4.3.10-12 PEAR - PHP Extension and Applicati ii postfix [mail-transport-agen 2.1.5-9 A high-performance mail transport pn wwwconfig-common Not found. --------------------------------------- Received: (at 306997-close) by bugs.debian.org; 19 May 2005 21:21:46 +0000 >From katie(a)ftp-master.debian.org Thu May 19 14:21:46 2005 Return-path: <katie(a)ftp-master.debian.org> Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DYsSg-0005zY-00; Thu, 19 May 2005 14:21:46 -0700 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DYsOd-0007we-00; Thu, 19 May 2005 17:17:35 -0400 From: Hilko Bengen <bengen(a)debian.org> To: 306997-close(a)bugs.debian.org X-Katie: $Revision: 1.55 $ Subject: Bug#306997: fixed in drupal 4.5.2-4 Message-Id: <E1DYsOd-0007we-00(a)newraff.debian.org> Sender: Archive Administrator <katie(a)ftp-master.debian.org> Date: Thu, 19 May 2005 17:17:35 -0400 Delivered-To: 306997-close(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: X-CrossAssassin-Score: 3 Source: drupal Source-Version: 4.5.2-4 We believe that the bug you reported is fixed in the latest version of drupal, which is due to be installed in the Debian FTP archive: drupal_4.5.2-4.diff.gz to pool/main/d/drupal/drupal_4.5.2-4.diff.gz drupal_4.5.2-4.dsc to pool/main/d/drupal/drupal_4.5.2-4.dsc drupal_4.5.2-4_all.deb to pool/main/d/drupal/drupal_4.5.2-4_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 306997(a)bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Hilko Bengen <bengen(a)debian.org> (supplier of updated drupal package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster(a)debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.7 Date: Thu, 19 May 2005 21:23:27 +0200 Source: drupal Binary: drupal Architecture: source all Version: 4.5.2-4 Distribution: unstable Urgency: low Maintainer: Hilko Bengen <bengen(a)debian.org> Changed-By: Hilko Bengen <bengen(a)debian.org> Description: drupal - fully-featured content management/discussion engine Closes: 301394 301946 306997 Changes: drupal (4.5.2-4) unstable; urgency=low . * [Miguel Figueiredo <elmig(a)debianpt.org>] Added Portuguese translation (Closes: #301394) * [Valentina Commissari <ayor(a)quaqua.net>] Added Italian translation (Closes: #301946) * [Gleydson Mazioli da Silva <gleydson(a)debian.org>] Updated Brazilian Portuguese translation. * Fixed typo in package description (Closes: #306997) Files: f36a5fd78d26ebb6c9935d9569cc5130 609 web extra drupal_4.5.2-4.dsc 8ec0c830ae5fa35def8748bc0c215704 38367 web extra drupal_4.5.2-4.diff.gz 30333b315df4c7e169d2ea527b01a41c 484812 web extra drupal_4.5.2-4_all.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCjP3WUCgnLz/SlGgRArERAJ9ncqDeD/Rk2jjYdcTZYHlyhmO/9QCfW/Gn Y4dwFZSdXMrCAy7xoYrVO0Y= =71Pz -----END PGP SIGNATURE-----

1 0

[drupal-devel] Bug#301946: marked as done (drupal: Italian po file translation)
by owner＠bugs.debian.org 19 May '05

19 May '05

Your message dated Thu, 19 May 2005 17:17:35 -0400 with message-id <E1DYsOd-0007wc-00(a)newraff.debian.org> and subject line Bug#301946: fixed in drupal 4.5.2-4 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 29 Mar 2005 08:59:10 +0000 >From ayor(a)quaqua.net Tue Mar 29 00:59:09 2005 Return-path: <ayor(a)quaqua.net> Received: from adsl-2-61.38-151.net24.it (psychick) [151.38.61.2] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DGCZ2-00042W-00; Tue, 29 Mar 2005 00:59:08 -0800 Received: by psychick (Postfix, from userid 1001) id E403537F2B; Tue, 29 Mar 2005 10:57:01 +0200 (CEST) Date: Tue, 29 Mar 2005 10:57:01 +0200 From: Valentina <ayor(a)quaqua.net> To: Debian Bug Tracking System <submit(a)bugs.debian.org> Subject: drupal: Italian po file translation Message-ID: <20050329085701.GA2383@psychick> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline X-Reportbug-Version: 3.8 X-Debbugs-Cc: ayor(a)quaqua.net User-Agent: Mutt/1.5.6+20040907i Content-Transfer-Encoding: 7bit Delivered-To: submit(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-11.0 required=4.0 tests=BAYES_00,HAS_PACKAGE, X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Package: drupal Version: 4.5.2-3 Severity: wishlist Tags: patch l10n I attach the Italian po translation. Please add it to the package. Thanks Valentina Commissari -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages drupal depends on: pn apache | apache-ssl | apache- Not found. ii debconf 1.4.30.11 Debian configuration management sy ii makepasswd 1.10-2 Generate and encrypt passwords pn mysql-client | virtual-mysql- Not found. pn php4-cli Not found. pn php4-mysql | php4-pgsql Not found. ii postfix [mail-transport-agent 2.1.5-6 A high-performance mail transport pn wwwconfig-common Not found. --FCuugMFkClbJLl1L Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="it.po" Content-Transfer-Encoding: quoted-printable # Italian translation of debconf for Drupal. # This file is distributed under the same license as the Drupal package. # Copyright 2005 by Valentina Commissari <ayor(a)quaqua.net>. msgid "" msgstr "" "Project-Id-Version: Drupal 4.5.2-3\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2005-02-06 00:26+0100\n" "PO-Revision-Date: 2005-03-29 10:50+0100\n" "Last-Translator: Valentina Commissari <ayor(a)quaqua.net>\n" "Language-Team: Italian <debian-l10n-italian(a)lists.debian.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=3Dutf-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Poedit-Language: Italian\n" "X-Poedit-Country: ITALY\n" "X-Poedit-SourceCharset: utf-8\n" #. Type: boolean #: ../templates.master:4 msgid "Automatically create Drupal database?" msgstr "Creare automaticamente il database di Drupal?" #. Type: boolean #: ../templates.master:4 msgid "Drupal needs access to a database, along with initialized data str= uctures in order to function properly. This can be created automatically = by this package, for MySQL or PostgreSQL databases." msgstr "Drupal necessita dell'accesso ad un database, associato a struttu= re dati inizializzate per far s=EC che funzioni correttamente. Questo puo= ` essere creato automaticamente da questo pacchetto, per database come My= SQL o PostgreSQL." #. Type: boolean #: ../templates.master:4 msgid "Automatically creating the database does not make sense if a Drupa= l database already exists or if no database server has been setup when Dr= upal is installed." msgstr "Creare automaticamente il database non ha senso se esiste gia` un= database di Drupal o se non e` stato impostato un server per database qu= ando Drupal e` stato installato." #. Type: boolean #: ../templates.master:16 msgid "Run database update script?" msgstr "Eseguire lo script di aggiornamento database?" #. Type: boolean #: ../templates.master:16 msgid "If you are upgrading Drupal from an older upstream version, the da= tabase structure needs to be updated. This package can perform this task = automatically." msgstr "Se si sta aggiornando Drupal da una versione piu` vecchia, la str= uttura del database necessita di essere aggiornata. Questo pacchetto puo`= svolgere questa funzione automaticamente." #. Type: boolean #: ../templates.master:16 msgid "A manual update procedure is available by pointing a web browser t= o <http://$SITE/update.php>." msgstr "Una procedura di aggiornamento manuale e` disponibile andando con= un browser all'indirizzo: <http://$SITE/update.php>." #. Type: boolean #: ../templates.master:16 msgid "The database will be backed up to prevent data loss." msgstr "Il database sara` salvato in un backup per prevenire perdite di d= ati." #. Type: select #: ../templates.master:30 msgid "Database engine to be used with Drupal" msgstr "Motore del database da essere usato con Drupal" #. Type: string #: ../templates.master:35 msgid "Database server for Drupal's database" msgstr "Server del database per il database di Drupal" #. Type: string #: ../templates.master:40 msgid "Database server administrator user name on host ${host}" msgstr "Nome dell'amministratore del server del database sull'host ${host= }" #. Type: password #: ../templates.master:45 msgid "Password for database server administrator ${user} on host ${host}= " msgstr "Password per l'amministratore del server del database ${user} sul= l'host ${host}" #. Type: password #: ../templates.master:45 msgid "The answer will not be stored anywhere permanently." msgstr "La risposta non sara` permanentemente archiviata." #. Type: string #: ../templates.master:51 msgid "Drupal database owner username" msgstr "Nome del proprietario del database di Drupal" #. Type: string #: ../templates.master:51 msgid "This username will be used by Drupal to connect to the database se= rver." msgstr "Questo nome sara` usato da Drupal per connettersi al server del d= atabase." #. Type: password #: ../templates.master:57 msgid "Drupal database owner password" msgstr "Password del proprietario del database di Drupal" #. Type: password #: ../templates.master:57 msgid "If no password is specified here, a random password will be genera= ted." msgstr "Se qui non viene specificata nessuna password, ne sara` generata = una casuale." #. Type: string #: ../templates.master:64 msgid "Drupal database name" msgstr "Nome del database di Drupal" #. Type: boolean #: ../templates.master:69 msgid "Remove Drupal database when the package is removed?" msgstr "Rimuovere il database di Drupal quando il pacchetto viene rimosso= ?" #. Type: boolean #: ../templates.master:74 msgid "Remove former database backups when the package is removed?" msgstr "Rimuovere i vecchi backup del database quando il pacchetto viene = rimosso?" #. Type: boolean #: ../templates.master:74 msgid "These backups are stored in /var/lib/drupal/backups. This will not= remove the current database from the DBMS." msgstr "Questi backup sono salvati in /var/lib/drupal/backups. Questo non= rimuovera` l'attuale database dal DBMS." #. Type: multiselect #: ../templates.master:82 msgid "Web server(s) that should be configured automatically" msgstr "I server web che devono essere automaticamente configurati" #. Type: note #: ../templates.master:86 msgid "User creation failed" msgstr "Creazione dell'utente fallita" #. Type: note #: ../templates.master:93 msgid "Attempt to modify config file ${conffile} failed" msgstr "Tentativo di modificare il file di configurazione ${conffile} fal= lito" #. Type: note #: ../templates.master:100 msgid "Database creation failed" msgstr "Creazione del database fallita" #. Type: note #: ../templates.master:107 msgid "Database initialization failed" msgstr "Inizializzazione del database fallita" #. Type: note #: ../templates.master:114 msgid "Automatic database update failed" msgstr "Aggiornamento automatico del database fallito" #. Type: note #: ../templates.master:114 msgid "The automatic update script failed to update the database." msgstr "Lo script di aggiornamento automatico ha fallito nell'aggiornare = il database" #. Type: note #: ../templates.master:123 msgid "Automatic update script can not be run" msgstr "Lo script di aggiornamento automatico non puo` essere eseguito" #. Type: note #: ../templates.master:123 msgid "Configuration files of a Drupal package ${oldversion} have been fo= und, but the package itself has been removed. Therefore, it is not possib= le to run the automatic update script." msgstr "Sono stati trovati file di configurazione di un pacchetto Drupal = ${oldversion}, ma lo stesso pacchetto e` stato rimosso. Per questo motivo= non e` possibile eseguire lo script di aggiornamento automatico." #. Type: note #: ../templates.master:123 msgid "Please run it by hand after the package has been successfully inst= alled. Either point your web browser to ${site_root}/update.php or run /u= sr/share/drupal/scripts/debian-update.php from a shell." msgstr "Eseguirlo manualmente dopo che il pacchetto e` stato installato c= on successo. Tramite un browser web andare all'indirizzo ${site_root}/upd= ate.php o eseguire /usr/share/drupal/scripts/debian-update.php da una she= ll." #. Type: note #: ../templates.master:135 msgid "Database removal failed" msgstr "Rimozione del database fallita" #. Type: note #: ../templates.master:135 msgid "Script output:" msgstr "Output dello script:" #. Type: note #: ../templates.master:135 msgid "${result}" msgstr "${result}" --FCuugMFkClbJLl1L-- --------------------------------------- Received: (at 301946-close) by bugs.debian.org; 19 May 2005 21:21:45 +0000 >From katie(a)ftp-master.debian.org Thu May 19 14:21:45 2005 Return-path: <katie(a)ftp-master.debian.org> Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DYsSf-0005zL-00; Thu, 19 May 2005 14:21:45 -0700 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DYsOd-0007wc-00; Thu, 19 May 2005 17:17:35 -0400 From: Hilko Bengen <bengen(a)debian.org> To: 301946-close(a)bugs.debian.org X-Katie: $Revision: 1.55 $ Subject: Bug#301946: fixed in drupal 4.5.2-4 Message-Id: <E1DYsOd-0007wc-00(a)newraff.debian.org> Sender: Archive Administrator <katie(a)ftp-master.debian.org> Date: Thu, 19 May 2005 17:17:35 -0400 Delivered-To: 301946-close(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: X-CrossAssassin-Score: 2 Source: drupal Source-Version: 4.5.2-4 We believe that the bug you reported is fixed in the latest version of drupal, which is due to be installed in the Debian FTP archive: drupal_4.5.2-4.diff.gz to pool/main/d/drupal/drupal_4.5.2-4.diff.gz drupal_4.5.2-4.dsc to pool/main/d/drupal/drupal_4.5.2-4.dsc drupal_4.5.2-4_all.deb to pool/main/d/drupal/drupal_4.5.2-4_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 301946(a)bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Hilko Bengen <bengen(a)debian.org> (supplier of updated drupal package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster(a)debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.7 Date: Thu, 19 May 2005 21:23:27 +0200 Source: drupal Binary: drupal Architecture: source all Version: 4.5.2-4 Distribution: unstable Urgency: low Maintainer: Hilko Bengen <bengen(a)debian.org> Changed-By: Hilko Bengen <bengen(a)debian.org> Description: drupal - fully-featured content management/discussion engine Closes: 301394 301946 306997 Changes: drupal (4.5.2-4) unstable; urgency=low . * [Miguel Figueiredo <elmig(a)debianpt.org>] Added Portuguese translation (Closes: #301394) * [Valentina Commissari <ayor(a)quaqua.net>] Added Italian translation (Closes: #301946) * [Gleydson Mazioli da Silva <gleydson(a)debian.org>] Updated Brazilian Portuguese translation. * Fixed typo in package description (Closes: #306997) Files: f36a5fd78d26ebb6c9935d9569cc5130 609 web extra drupal_4.5.2-4.dsc 8ec0c830ae5fa35def8748bc0c215704 38367 web extra drupal_4.5.2-4.diff.gz 30333b315df4c7e169d2ea527b01a41c 484812 web extra drupal_4.5.2-4_all.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCjP3WUCgnLz/SlGgRArERAJ9ncqDeD/Rk2jjYdcTZYHlyhmO/9QCfW/Gn Y4dwFZSdXMrCAy7xoYrVO0Y= =71Pz -----END PGP SIGNATURE-----

1 0

[drupal-devel] [task] Better formatting of sizes.
by drumm 19 May '05

19 May '05

Issue status update for http://drupal.org/node/23211 Project: Drupal Version: cvs Component: base system Category: tasks Priority: minor Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/common.inc_3.diff (662 bytes) format_size(1024) currently returns "1024 bytes" when it would be a bit nicer to say "1 KB". drumm

2 2

[drupal-devel] drupal.css, again (still)
by Bèr Kessels 19 May '05

19 May '05

A lot has been discussed about this, but as of yet nothing solved. Can we discuss this, **but with the aim to come to an agreement?** Personally I am really annoyed by the drupal.css and remove it nearly always. But it is correct to state that drupal.css must be there, for usability sake. A lot of (especially admin) pages will not work without some CSS. But that is definitely no excuse for all sorts of background-colors, font-sizes, borders etc, that are in that sheet. So, to get to a conclusion; I think we should *not* discuss whether or not drupal.css must be there, we will never come to an agreement on that. it will remain, unless someone patches a very nice solution. But we should discuss what can be in there and what not! My first idea is, drupal.css must contain * No colours, nor background colours, unless they greatly enhance useability. think of watchdog entries. But not tables, grey tables are nice, but should be styled by the theme; * No borders, paddings or margins, *unless* a page will break without them [1] * No floats, breaks, displays, centres or other things that manipulate the flow, *unless* a page will break without them. [2] * No widths, unless they are really needed to make floated erlements appear on the same line. with:100% is very annoying due to the famous border-box-model. [1] usefull: ul.primary li.active a { background-color: #fff; border: 1px solid #bbb; annoying: .tips { margin-top: 0; margin-bottom: 0; [2] usefull: br.clear { clear: both; } annoying: #aggregator .news-item .date { float: left; } or even more annoying .user-login-block { text-align: center; } Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

11 31

[drupal-devel] [feature] Make FactoryJoe happy -- overrideable drupal.css
by chx 19 May '05

19 May '05

Issue status update for http://drupal.org/node/23210 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/theme_settings_0.patch (913 bytes) End the endless debates and provide a theme overrideable hook for include misc/drupal.css. The idea (partially) comes from FactoryJoe. chx

6 5

[drupal-devel] OpenID: Open Source Sing Sign-On
by K B 19 May '05

19 May '05

This is an article on Slashdot with yet another standard. I personally do not favor sing sign on schemes, but many of you would be interested in this, and perhaps making Drupal work with it. http://it.slashdot.org/article.pl?sid=05/05/19/1451231&tid=95

1 0

[drupal-devel] [bug] Put revisions in their own table
by killes 19 May '05

19 May '05

Issue status update for http://drupal.org/node/7582 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org Status: patch Dries: Can you please let me have your updated database? I want to have a look at it and try my own benchmarks with it. And yes, if I did learn something on this project is how to be persistant. ;) killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ May 5, 2004 - 18:25 : killes(a)www.drop.org Currently all node revisions are stored in a serialized field in node.table and retrieved for _each_ page view although they are rarely needed. However, we have agreed that serializing data is bad and that we should try to keep the memory foot print pf Drupal small. Therefore I propose to create a separate revisions table which would be in principle identical to the node table, only that it could have several old copies of the same node. Extra data added by other modules could be added in a serialized field unless we find a better solution. ------------------------------------------------------------------------ May 5, 2004 - 19:06 : jhriggs I too think the serialized approach is less than desirable, but here's an alternative. This would likely take some considerable rework in core and contrib, but the following is how we handle similar types of situations in our databases at work. It is more elegant that a separate table, and avoids the (almost exact) duplication of a table. Instead of separate tables, keep all revisions of nodes in the node table as follows: * add field: active (0/1 or Y/N) * add field: revision * every revision of a node is stored in the node table; however, only one revision can be active at any given time * nid can no longer be unique -- primary/unique key becomes (nid, active) * any time a node is loaded, updated (without revision), etc., the active version is used. Thoughts? ------------------------------------------------------------------------ May 5, 2004 - 19:57 : killes(a)www.drop.org I am not opposed to your scheme, but I want to stress the following: * Duplicating a table's structure is not bad (IMHO) as long as the content is different. * having two tables will allow us to have a rather small node table. This is (maybe) a performance gain. ------------------------------------------------------------------------ May 5, 2004 - 20:37 : jhriggs I don't necessarily think that duplicating a table's structure is _bad_. It just seems to be wasteful and a pain to maintain. (Every change to the node table is made twice...easy to do, but also easy to miss perhaps.) As for performance, as long as nid and the active indicator are indexed, there shouldn't be any performance loss. Also, archiving an old version when making a new revision will be much simpler: just change the active indicator rather than copying an entire node to another table (and ensuring everything gets copied...again a potential maintainance issue). To be honest, I would just like to see the serialized data go away, regarless of what approach is taken. ------------------------------------------------------------------------ July 30, 2004 - 21:49 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_07-30-2004.p… (10.47 KB) I'm interested in using Drupal for a large scale wiki-type project. In order to do this, I need revisions to be in their own table. Attached is a patch to do just that. Most of the changes are pretty self explanatory. Spreading out node data across two tables meant that I had to add database functions to do locking/transactions. Without this, race conditions in which the database becomes corrupted are possible. ------------------------------------------------------------------------ July 30, 2004 - 21:54 : Nick Nassar Oh yeah... The patch is a diff against Drupal CVS ------------------------------------------------------------------------ July 31, 2004 - 02:00 : Anonymous Gerhard speaking. Nick, thanks a lot for your nice patch! It saves me a great deal of labour. I looked through it and immediately liked it. You not only put the old revisions into a new table but also the current one. Do you have an estimate how much more expensive the additional join is? Besides a few minor coding style issues I found a major one: Just a few hours before you uploaded your patch JonBob's node access patch hit core. That means your patch won't apply anymore as all the queries you change have been changed. Can I bug you to update your patch? ------------------------------------------------------------------------ July 31, 2004 - 03:11 : Anonymous Also I think that your upgrade path loses existing revisions. ------------------------------------------------------------------------ July 31, 2004 - 04:39 : drumm I think this is the proper way to do things. No columns are duplicated, there is no serialized data, and only the fields that are logically revised are stored. Nothing jumped out at me as a way to have my node modules be able to keep a table of revisions of additional fields. I'm guessing this could be done within the confines of _insert and _update. Assuming the upgrade path works and modules can extend it I give it a +1. ------------------------------------------------------------------------ July 31, 2004 - 16:40 : Nick Nassar It figures that just as I finish a big patch, another patch comes along and breaks it. Oh well, it should be a pretty easy to fix. I'll work on it. Fixing the upgrade path to keep revisions should be fairly painless. I found another issue that needs to be fixed before this patch gets merged. There format of a node needs to be stored for each revision. Otherwise, for modules that store a format for the nodes, such as page and book, if you write one revision in PHP and the next in HTML, the PHP revision will be displayed as HTML. This is part of a larger issue of how node modules should store revisions of additional fields. I think each module that wants to do this should create another table with (nid, revid) as the primary key. Just as when they want to add fields to a node they create another table with nid as the primary key. As far as performance goes, for sites that make heavy use of revisions, an extra join on primary keys is going to be a lot faster than grabbing all of the revisions from that database everytime. We would need to run benchmarks to determine is the overall difference in speed is for an average site is a gain or a loss. I'm guessing it's very minor either way. ------------------------------------------------------------------------ August 23, 2004 - 15:55 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_08-23-2004.p… (10.92 KB) Here's an updated patch against CVS that puts revisions in their own table, provides an upgrade path, and fixes the format related bugs in the last patch. Hopefully, this can make it into CVS as soon as the freeze is over. ------------------------------------------------------------------------ August 23, 2004 - 16:10 : moshe weitzman Interesting patch ... drumm's question is still outstanding. how do modules store revisions of their fields? Are they expected to manage this on their own? Thats not how it works today. As an aside, i am seeing profile_ fields in my node.revisions column. One could argue that those need not be saved. They pertain to the node author, not to the node itself. ------------------------------------------------------------------------ August 23, 2004 - 18:14 : Nick Nassar Having modules be responsible for storing revisions of their own fields is a side-effect of storing revision data in tables. There's really no way around it. However, revisions generally don't make sense for node types that don't have PHP/HTML content, such as polls. I think it's going to be a pretty rare scenario for a new node type to want another field to change per-revision, so it's a pretty good trade-off. Storing fields that shouldn't be part of revisions, such as the profile_ fields, is a side-effect of storing revisions as serialized objects. Applying this patch will free up that wasted space. :) ------------------------------------------------------------------------ August 23, 2004 - 19:20 : Anonymous There should be a hook that let's the module choose whether it supports history. This way a module author can prevent the user from doing something that may break his module or just cause undefined behavior. If the module doesn't support history then don't let the user/admin choose to add history to nodes of that type. Craig ------------------------------------------------------------------------ August 23, 2004 - 21:23 : Nick Nassar I agree, there should be an API change to make specifying support for revisions easier. In the interests of keeping patches small and keeping to one change per patch, I think the API change should be a separate issue. A sort of ad-hoc API to decide whether or not a module supports revisions by default already exists. Instead of having a hook, modules set the default value of the "Create new revision" field in the edit form. The admin can change this option in admin/node/configure/defaults. This patch doesn't change that. Revisions are broken for node types that have their own database structure, like polls, even when storing them as serialized objects. This patch doesn't change that, either. ------------------------------------------------------------------------ October 26, 2004 - 04:35 : moshe weitzman I'm guessing that someone is going to have to demonstrate that this patch performs as well as current drupal before it gets comitted. i think this patch is a few benchmarks from being comitted. ------------------------------------------------------------------------ October 27, 2004 - 03:04 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004.p… (11 KB) I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ October 27, 2004 - 03:05 : Nick Nassar I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ October 27, 2004 - 03:05 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004.p… (11 KB) I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ November 15, 2004 - 07:05 : elias1884 please overthink the revision system default workflow as well. don't look at the revision system as an isolated system but as a part of the whole workflow system! if you combine revisions with the moderation queue the most logic default workflow would be like that: auth user creates node (revision #0) admin approves the node (status = 1, moderation = 0) => node publicly available auth user finds typo and changes node (revision #1, status = 0, moderation = 1) ------- what happens at that point at the moment is, that the node is not accessible anymore at all until the new revision is approved by admin. of course the new revision should not go online until reviewed and approved, this is absolutely correct, but there is no reason to not take the old revision offline, since it was already approved and should therefore be online until the new revision is approved. it is not practical if a node disappears only because the author corrected a typo. ------- admin approves the node (status = 1, moderation = 0) eventhough I first thought a plain boolean active field would not be capable of providing that functionality if finally came to the conclusion, that it can. The only thing to do is to not set that bit, when a new revision is created, but when it is approved (in case moderation is activated under default workflow). Every revision should have its own moderation, status and active field and on approval they are set like this (status=1, moderation=0, active=Y). When you wanna rollback to an old revision, you can chose between all revisions that already have the moderation bit set back to 0 again and the published to 1. There should be an extra permission for rollback! another concern that I have about the default workflow is, that users can't see the content, they have just created, when moderation is enabled. Eventhough, there is a big fat "submission accepted" presented after submissions, unexperienced users tend to question the information those stupid tincans give them, if they can't find their content afterwards. Many users are really lazy bastards and they don't even read the status messages. The best feedback about whether his story was submitted successfully or not of course is, if he can find the story somewhere on the site, maybe with a status message on top of it, mentioning, that the content is currently not publicly available since it has not been approved yet. there should be a my content section under my account, like somebody is trying to do with the workspace module I guess. so my suggestion is to make (status=0, moderation=1) still available for the creator under a my content section somewhere! ------------------------------------------------------------------------ November 24, 2004 - 06:21 : Nick Nassar I agree. The current workflow for moderation queues and revisions needs to change, but this patch isn't the place for it. The patch is already too big, and it only does the backend stuff. Instead of adding more to this patch and making it take even longer to get into core, would you mind creating a new issue for your UI suggestions, so the those changes can be added as a separate patch? Thanks, Nick ------------------------------------------------------------------------ December 11, 2004 - 14:26 : Dries This patch is _much_ needed so I'd love to see someone revive it. In order for this patch to be accepted, the following needs to be done: Update this patch to CVS HEAD. Rename revid to vid. Rename node_rev to node_revisions. Rename node_rev.changed to node_revisions.timestamp. Rename $rnode to $revision. Fix the coding style to match Drupal's: proper spacing, single quotes where possible, proper variable names. Benchmark this patch with a large database with enough revisions. I'd be happy to benchmark this on my local copy of the drupal.org database. The book.log field should probably move to the node_revisions table. This can be done in a separate patch. Investigate whether transactions are well-supported. ------------------------------------------------------------------------ December 13, 2004 - 02:25 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004-r… (11.02 KB) I've worked a bit on the patch (coding style issues as mentioned by Dries). One thing I noticed is that the patch uses REPLACE. IIRC this needs to be chagned to "UPDATE, if fail INSERT" for pgsql compatibility. Nick, are you still interested in working on that patch? I'd like to know how it works on your site and work on getting it into core. ------------------------------------------------------------------------ December 13, 2004 - 14:33 : Dries Gerhard: your patch does not apply. ------------------------------------------------------------------------ December 13, 2004 - 19:10 : killes(a)www.drop.org Yes, I know, that was the same version as I mailed to you earlier. ------------------------------------------------------------------------ December 13, 2004 - 23:02 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions.patch (52.96 KB) Ok, upüdated the patch to cvs. ------------------------------------------------------------------------ December 14, 2004 - 10:58 : Dries Some more comments: db_begin_transaction() and db_end_transaction() do not belong in database.inc, but in database.mysql.inc and database.pgsql.inc respectively. The node module calls node_revisionsision_list() which is not defined. (Fxed that on my local copy.) Do db_begin_transaction() and db_end_transaction() deprecate Jeremy's table locking patch? The upgrade path assigns the wrong user ID to each revision. The upgrade path assigns the wrong date to each revision (that or a node's revision page shows the wrong usernames/dates). The coding style needs a bit of work, but we can worry about that later. ------------------------------------------------------------------------ December 14, 2004 - 19:34 : Nick Nassar If you need any help getting those things fixed, just let me know. ------------------------------------------------------------------------ December 14, 2004 - 19:50 : Nick Nassar How this relates to Jeremy's node locking patch: There was lots of discussion, and node locking was decided against because from an end user point of view you never want a node to be locked. He's now advocating for a much simpler patch that warns users if their changes will overwrite someone elses. That patch still has a race condition, which might be fixed using db_begin_transaction(). http://drupal.org/node/6025 ------------------------------------------------------------------------ December 15, 2004 - 00:26 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_0.patch (55.96 KB) Here is an updated patch that tries to address Dries concerns. ------------------------------------------------------------------------ December 15, 2004 - 10:32 : Dries Attachment: http://drupal.org/files/issues/revisions-bug.png (76.06 KB) It didn't fix the aforementioned bugs. See attached screenshot. ------------------------------------------------------------------------ January 6, 2005 - 22:15 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_1.patch (51.77 KB) Ok, here is a new version. Dries and myself worked hart at it, so please have a look. what is still missing - database upgrades for the core modules with an own table - contrib modules need an upgrade too. - do we need nid and vid in both the node and the node_revisions table? - the amount of sql queries means a good stress testing for large databases. ------------------------------------------------------------------------ January 19, 2005 - 23:43 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_2.patch (49.49 KB) Here is an updated patch. We discussed to keep the current title in node module and also in the revisiosn table. This is content duplication but will save many joins as many queries only need the title of a node. Discussion is welcome. ------------------------------------------------------------------------ January 20, 2005 - 01:33 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_3.patch (29.93 KB) I've implemented the aforementioned solution. This makes the patch much smaller. The patch now also removes taxonomy_node_has_term() which wasn't used anywhere. I'd really apprciate if some people could test drive the patch. It will be another huge improvement for 4.6. ------------------------------------------------------------------------ January 20, 2005 - 02:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_4.patch (30 KB) Another revision. Steven didn't like my literal $node->vid in queries. ------------------------------------------------------------------------ January 20, 2005 - 03:10 : killes(a)www.drop.org - database upgrades for the core modules with an own table - contrib modules need an upgrade too. - do we need nid and vid in both the node and the node_revisions table? - the amount of sql queries means a good stress testing for large databases. These issues are still open, btw. Especially the first one needs to be tackled. ------------------------------------------------------------------------ January 25, 2005 - 22:11 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_5.patch (51.13 KB) Here is a patch that has the database tables updated for forum, book, and page module. ------------------------------------------------------------------------ January 30, 2005 - 00:55 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_6.patch (49.18 KB) Yet another update to keep it working with head. The patch now also removes the table definitons for the page table. ------------------------------------------------------------------------ January 30, 2005 - 00:57 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_7.patch (55.69 KB) Sorry, that was the old version, this is the right one. ------------------------------------------------------------------------ January 31, 2005 - 21:55 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_8.patch (55.71 KB) Updated once more. ------------------------------------------------------------------------ January 31, 2005 - 22:52 : Dries Anyone to help review/test this? ------------------------------------------------------------------------ January 31, 2005 - 23:22 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_9.patch (49.29 KB) Updated again, the update functions occurred twice. Thanks Bart. ------------------------------------------------------------------------ February 2, 2005 - 02:27 : killes(a)www.drop.org Don't know if the db I am using is corrupted or what. I still do have some didficulties. The latest patch is attached. ------------------------------------------------------------------------ February 2, 2005 - 02:27 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_10.patch (49.67 KB) I am probably slowly going mad ... ------------------------------------------------------------------------ February 2, 2005 - 03:54 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_11.patch (48.95 KB) The update issue still needs investigating. This patch is updated for cvs. ------------------------------------------------------------------------ February 2, 2005 - 22:20 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_12.patch (49.83 KB) Ok, here is a new version. I've solved my troubles with book.module. There are still some issues with forum module. Possibly due to inconsistent database. ------------------------------------------------------------------------ February 2, 2005 - 23:31 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_13.patch (49.83 KB) Turns out the drupal.org database had indeed some quirks. Please run this query in your oldest db and tell me the result: select nid,type from node where type like '%/%'; If you get a non-zero result we might need to add another security update. The patch could use still more testing, though. ------------------------------------------------------------------------ February 3, 2005 - 03:16 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_14.patch (49 KB) Ok, we are getting somewhere. At a first glance the update is working. There is a problem remaining: the revisions tab will be shown whether the node has revisions or not. Not sure we can/need to fix this. People with a drupal.org account can log in at http://killes.drupaldevs.org/revision/ and poke around. Your permissions will be the same as on drupal.org. Feel free to vreak everything but don't forget to file complaints here. (Note: this is only a pruned version of the drupal.org database with all project nodes and nodes with nids > 7000 dropped). ------------------------------------------------------------------------ February 3, 2005 - 06:19 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_15.patch (52.39 KB) There was some error in node_save and also the patches to the database.inc files got lost... ------------------------------------------------------------------------ February 3, 2005 - 09:07 : robertDouglass Submitting book pages doesn't work on your test site. It puts the entire content of the preview inside the body textarea. I wrote a sentence in the body and the log, and pressing preview put several lines of HTML containing both sentences in the body textarea on the preview page, plus the book page wouldn't submit. -R ------------------------------------------------------------------------ February 3, 2005 - 09:50 : Junyor 0 results here. I started using Drupal with version 4.4, though. ------------------------------------------------------------------------ February 4, 2005 - 01:56 : killes(a)www.drop.org @Junyor: Thanks, that's a good sign. Maybe somebody else has an older db to try. @robertDouglass: The first effect you describe is due to drupaldevs running on PHP 5. I am unsure why the second thing does not work. In node_save() the node object has a nid although there is none in the form. Very strange. I've enabled display of db queries on the testsite. ------------------------------------------------------------------------ February 4, 2005 - 21:17 : dmjossel No results here on the query: select nid,type from node where type like '%/%'; On a database that was put in place prior to Drupal 4 and is now running on 4.5.2. ------------------------------------------------------------------------ February 4, 2005 - 22:44 : killes(a)www.drop.org @dmjossel: thanks. @all. The strange problem I reported was apparently php 5 related. After applying Steven's php 5 patch it went away. One error is remaining: If I create a new forum topic it will be shown as part of the book on preview. Hmm, that was due to a db that got corrupted during testing so that is fixed too. Please poke around at the test site and look if you find more errors. ------------------------------------------------------------------------ February 5, 2005 - 09:16 : Steven By the way, I just remembered that Drupal.org has some blogs lingering on in the database even though blog.module is not enabled. Perhaps this is causing troubles? ------------------------------------------------------------------------ February 5, 2005 - 13:22 : Anonymous I can't see why it would. Drupal.org will need extra updates for images and project nodes because those have their own tables. GK. ------------------------------------------------------------------------ February 6, 2005 - 14:49 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_16.patch (52.49 KB) Updated to apply to cvs again. ------------------------------------------------------------------------ February 22, 2005 - 22:15 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_17.patch (49.64 KB) Updated again. All we need is a patch to upload module and an upgrade path for it. ------------------------------------------------------------------------ March 4, 2005 - 06:22 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_18.patch (52.31 KB) Updated once more. Moved log field from book to node_revisions table as discussed in Antwerp. upload module still missing. We need to decide under which circumstances the log field should be displayed. Should that be added to the workflow? Should it depend on the revisions setting? ------------------------------------------------------------------------ March 5, 2005 - 21:27 : Anonymous Attachment: http://drupal.org/files/issues/revisions_20.patch (75.52 KB) Ok, here it is: Yet another revision of this grrrrreat patch. Changes from previous versions: - supports versioning for uploaded files. A problem is that if you delete a file, it will be gone for all revisions. - the log field is now in the node_revsions table, but each module has to decide whether to show it or not. I've implemented it for the page and the book type odes. Also, the field can be edited when adding non-book nodes to the book. The log is displayed on the revisions page and if a node is moderated. - the revisions are moved to an old_revisions table to a) get the node table smaller and b) still leave the mavailable for contrib modules that want to retreive old version data. The patch has been applied to killes.drupaldevs.org/revision where it can be tested by anybody (especially people who have "site admin" rights on drupal.org) The database is from drupal.org and you should b able to log in with your pass or simply mail yourself a new one. Gerhard ------------------------------------------------------------------------ March 5, 2005 - 21:51 : Anonymous Attachment: http://drupal.org/files/issues/revisions_21.patch (59.42 KB) BTW, I marked this a bug because atm the revisions field can grow quite big. Neil has reported problems from some users who were not able to load some nodes due to to many large revisions. Also, som unrelated stuff crept into the patch. New version attached. ------------------------------------------------------------------------ March 8, 2005 - 07:56 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_22.patch (60.29 KB) Ok, I think I got it. Changes to last version: - uploads are no properly versioned. Missing are still pgsql checks and updates. ------------------------------------------------------------------------ March 10, 2005 - 18:58 : Anonymous Was able to get http://drupal.org/files/issues/revisions_21.patch to work with drupal-cvs.tar.gz (10 March 2005) by: - includes/database.mysql.inc: Commenting out duplicates for functions function db_begin_transaction and function db_commit_transaction - modules: node.module: Removing "'title' => $node->title," from $node_table_values variable declaration and removing "'title' => "'%s'"," from "$node_table_types" variable declaration. Happy to submit a patch if requested. I'll watch this thread. ------------------------------------------------------------------------ March 12, 2005 - 01:59 : killes(a)www.drop.org The duplicate function has been removed in rev 22 of this patch. Why do you think the changes in node_save are needed? Titles are saved in both tables for performance reasons. ------------------------------------------------------------------------ March 13, 2005 - 18:12 : jlerner Hi - I posted comment #62. The changes to node_save appear to be needed because recent patches (both 21 and 22) remove the field 'title' from table 'node'. So without the changes to node_save, node.module is broken and generates errors. Joshua ------------------------------------------------------------------------ March 13, 2005 - 18:29 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_23.patch (61.17 KB) Thanks, Joshua, for catching this. node:title is there to stay. ------------------------------------------------------------------------ April 13, 2005 - 18:29 : moshe weitzman since HEAD is open again, perhaps it is a good time to revisit this patch. once this is committed, lets address - http://drupal.org/node/11071 "node_validate does not respect group editing" ------------------------------------------------------------------------ April 18, 2005 - 17:43 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_24.patch (60.39 KB) Updated. ------------------------------------------------------------------------ April 18, 2005 - 18:16 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_24_0.patch (60.39 KB) Updated. ------------------------------------------------------------------------ April 19, 2005 - 07:19 : Dries I'll commit this patch later this week! If you haven't checked this patch already, I urge you to test/check it out because it will have significant impact on existing code and modules! ------------------------------------------------------------------------ April 19, 2005 - 07:21 : Dries Also, what do people think about the n.title being duplicated? ------------------------------------------------------------------------ April 19, 2005 - 07:26 : chx I won't lose any sleep because of duplicated titles... ------------------------------------------------------------------------ April 19, 2005 - 20:35 : killes(a)www.drop.org Let me explain why I have chosen to duplicate the title (and also the uid): If you look at all the queries in Drupal, you will find that most of them only need the title and th uid of a node. That is, by duplicating it, we save expensive joins on the node_revisions table. Due to this fact, this patch is actually a performance improvement. A note about updating contrib module: Strictly speaking they wouldn't need to be updated. They only need to if their authors decide that their info should be available for revisioning. The upgrade path for forum.module in my update.inc patch (+ the forum patch) should show you what needs to be done. I will write a note for the update page once the patch hits core. ------------------------------------------------------------------------ April 24, 2005 - 23:21 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_25.patch (60.38 KB) Updated to cvs. Dries: Based on some remarks in #drupal this is the last update I am going to do. Apply it or won't fix it. ------------------------------------------------------------------------ April 30, 2005 - 05:42 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/revisions_25.patch.patch (528 bytes) That's a big patch. I've only started looking through it. I noticed one little typo, affecting updates. A patch to your last patch is attached. I'm running with the revision patch on my dev server now happily. I like the concept. What happens if you click 'stop' on your browser in the middle of a MySQL "transaction"? I assume that kills the connection to MySQL, and the lock is freed? But this then leaves changes only partially applied? What exactly does locking/unlocking the tables buy us in MySQL? I don't see anywhere that we detect if an apply fails part way through, and thus roll back...? What am I missing? ------------------------------------------------------------------------ April 30, 2005 - 09:11 : Dries Jeremy: many of us are worried about the performance ramifications this patch introduces. Early experiments showed a small performance improvement (while a performance regression might be expected). More performance reports from large sites like kerneltrap.org will certainly help this patch. Mind to do a quick performance comparision and to report back with some numbers? Thanks. ------------------------------------------------------------------------ April 30, 2005 - 14:38 : Jeremy(a)kerneltrap.org Dries: I'm not running HEAD on kerneltrap, so this really isn't a possibility. Furthermore, until I understand why we're locking tables, I don't like it. The idea of revisions in their own tables is great. The idea of locking tables to get (without any obvious benefit) there really worries me. ------------------------------------------------------------------------ April 30, 2005 - 16:16 : killes(a)www.drop.org @Jeremy: Thanks for looking at the patch! Also for catching the typo. :) Did you try to upgrade your database? If yes, how did it go? One of Dries' concerns is the complexity of the upgrade. How many nodes and revisions did the db have? About database locking: This part of the patch was created by Nick and I simply continued to use it. Maybe the code should rather be: if(db_begin_transaction(array('{node}', '{node_revisions}', '{watchdog}', '{sessions}', '{files}'))) { db_query($node_query, $node_table_values); db_query($revisions_query, $revisions_table_values); db_commit_transaction(); ... } The idea is probably to avoid two updates at the same time. I don't think the locking helps if you abort the script at an inconvenient time. Rollbacks aren't implemented in all mysql versions. We could omit the db locking if deemed inappropriate. Maybe Nick can explain his ideas behind this. @Dries: I wonder who the "many of us" are. They certainly haven't spoken to me. Moshe had some reservations about the upgrade path and project module, but the time that project module abused revisions to store issue updates was long ago and his reservations were resolved. Nobody else (besides you of course and now Jeremy) has voiced reservations in a way that was audible to me. If you grep through the patch you will notice that there are only four queries which have a join on the node_revisions table. Two of them are in node_load and in the other cases the join replaced a join on the node table. The two queries in node_load are the only ones that have both a join on the node and the revisions query. Thus, loading of individual nodes might become somewhat slower. All other queries will be faster since the node table is now much smaller. Also, node loading does not have to be slower, it depends on your node table. If you had a lot of revisions and thus a large table, then the new scheme will make your queries actually faster since we do not load the revisions on each and every node load anymore. If you didn't have many revisions your node_load migth be somewhat slower. WRT to the update script Karoly pointed out that we could use multiple insert queries instead one query per revision. This would probably make the update somewhat faster. I am willing to work on this iff you declare that you will commit the patch afterwards. I'd need to know if this will work on pgsql and on all supported mysql versions before I work on it. About locking: Database locking is dog slow, at least on mysql. I was using locks in an earlier version of the upgrade script but had to remove it for (serious!) performance reasons. ------------------------------------------------------------------------ May 9, 2005 - 17:07 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_26.patch (46.45 KB) Ok, another update, cause I need it myself. I've left out the transaction stuff for now. It is in principle unrelated to this patch and should be discussed elsewhere. This also makes the patch smaller and easier to review (hint, hint). ------------------------------------------------------------------------ May 9, 2005 - 22:32 : killes(a)www.drop.org The patch contained the update functions twice. ------------------------------------------------------------------------ May 9, 2005 - 22:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_27.patch (39.05 KB) The patch contained the update functions twice. ------------------------------------------------------------------------ May 9, 2005 - 23:23 : Dries Got one error during the upgrade path: ALTER TABLE {book} ADD PRIMARY KEY vid (vid) FAILED ------------------------------------------------------------------------ May 9, 2005 - 23:26 : killes(a)www.drop.org This had happend to me as well, when I tested this patch. The reason is that for some reason the vid is not unique. Most likely there are some entries with vid = 0 in there. Can you check which node types those have? it always was an error in the test database. See: http://drupal.org/node/7582#comment-20678 ------------------------------------------------------------------------ May 9, 2005 - 23:27 : Dries Actually, I got 2850 errors during the upgrade. Some of these: sprintf() [function.sprintf]: Too few arguments in drupal-cvs/includes/database.inc on line 154. Some of these: Query was empty query: in drupal-cvs/includes/database.mysql.inc on line 66. And this: Unknown table 'n' in field list query: SELECT n.nid, n.vid FROM node INNER JOIN files f ON n.nid = f.nid in drupal-cvs/includes/database.mysql.inc on line 66. :-) ------------------------------------------------------------------------ May 9, 2005 - 23:29 : Dries Or this: user error: Unknown column 'log' in 'field list' query: SELECT parent, weight, log FROM book WHERE nid = 1 in drupal-cvs/includes/database.mysql.inc on line 66 ------------------------------------------------------------------------ May 9, 2005 - 23:52 : Dries The time required to generate my main page went from 902 ms (before upgrade) to 2139 ms (after upgrade). The time required to generate a forum listing (?q=forum/x) went from 1872 ms (before upgrade) to 2874 ms (after upgrade). Maybe this is because my database is not consistent as the result of the upgrade errors (yet I don't see any errors on the pages I benchmarked). ------------------------------------------------------------------------ May 10, 2005 - 02:24 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_28.patch (53.47 KB) Ok, let me get to this from the bottom to the top: - my test runs indicated a different development wrt timing. If I had gotten your results, I had stopped working on this long ago. So your results are wrong for some reason. - user error: Unknown column 'log' in 'field list' Wasn't my day, the book patch got lost. It is contained now. First -R the old patch, then apply this one. - Unknown table 'n' in field list query: Walkah found this, but I forgot to fix it. Fixed now. - I've no idea where the other queries come from. I am hoping that either your test db is borken or they are follow ups from the other ones. If you let me have your test db, I'll try some debugging. Thanks for wasting your time, too. ------------------------------------------------------------------------ May 10, 2005 - 07:07 : Dries I double-checked and the numbers don't seem to lie. I'll test some more after work on another machine to make sure it is not platform-specific. ------------------------------------------------------------------------ May 11, 2005 - 05:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_29.patch (54.83 KB) Ok, here I am again. What I did: 1) Ask Dries to let me have drupal.org database 2) get 400MB of SQL inserts... 3) take 23 minutes to import said data 4) Remove all image and project nodes (don't want to install their modules), 11765 nodes left 5) back up data 6) take tests on non-cached /node page (as anonymous user). ab results: -c 1 -n 25: Requests per second: 1.29 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 663 775 179.7 689 1264 7) Do the same for the tracker page: Requests per second: 0.83 [#/sec] (mean) Total: 1182 1199 7.4 1199 1217 8) Apply my patch (rev. 28). 9) run db update and hold breath 10) update times out... 11) play back backup from 5) 12) wait 13) getting annoyed and removing cache, watchdog, and accesslog before playing in backup. 14) wait again. Understand why Dries doesn't try this patch often. Maybe a smaller DB would do for testing? 15) wait more. get really annoyed. 16) Set time limit to 18000 in update.php 17) try again 18) fails again before the second update is completed. 19) curse. 20) delete search stuff from db. Ooops, sooo much smaller... 21) import again, below 2 minutes... 22) rewrite to use extended insert. Found a bug. 23) still does not complete. Mysql logging to the rescue! 24) tid = 0? Not good. 25) Well, the update works fine till node 10834. 5595 nodes done, 6136 to go. 26) Writing shell based update script. Discovery: 24MB aren't enough. Hopefully 64 are. Nope. extended inserts for revisions are apparently not the brightest idea: Huge memory consumption. Hmm, no, all updates got through. Selecting the revisions to put them into old_revisions table screwed it. Learned about CREATE TABLE old_revisions SELECT syntax. Yay! finally. 24 MB are just not enough the update.php script seems to still break. 27) Benchmarks! /node Requests per second: 1.54 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 632 649 40.5 636 791 /tracker Requests per second: 0.86 [#/sec] (mean) Total: 1119 1165 65.8 1160 1461 Ok: So we get an improvement for many node_loads, but none for simple selects from node. More tests can be done. 28) roll new patch Ain't Drupal fun? ------------------------------------------------------------------------ May 18, 2005 - 15:38 : Dries I did another round of tests on _another_ machine and it is not looking good: Before upgrade After upgrade ?q= (main page) 218 ms/request 340 ms/request ?q=forum (forum overview) 754 ms/request 1520 ms/request ?q=about (book page) 375 ms/request 5400 ms/request The upgrade process itself gave me a number of 'query was empty' and 'sprintf(): too few arguments' reports. Everything seems to work fine though. Looking at the ?q=about page, I see that the following query is executed twice _and_ that each time, it take more than 2 seconds to complete: SELECT n.nid, n.title, b.parent, b.weight FROM node n INNER JOIN book b ON n.vid = b.vid WHERE n.status = 1 AND n.moderate = 0 ORDER BY b.weight, n.title; --8 SHOW INDEX FROM book; +-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | book | 1 | book_parent | 1 | parent | A | 92 | NULL | NULL | | BTREE | | | book | 1 | nid | 1 | nid | A | 369 | NULL | NULL | | BTREE | | +-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 2 rows in set (0.00 sec) The book module does not appear to have a primary key? Sounds like a bad idea so I added one: mysql> ALTER TABLE book ADD PRIMARY KEY nid (nid); Query OK, 369 rows affected (0.02 sec) Records: 369 Duplicates: 0 Warnings: 0 Next, I wanted to make the vid column a unique key in all node tables: mysql> ALTER TABLE node ADD UNIQUE vid (vid); Query OK, 20392 rows affected (0.81 sec) Records: 20392 Duplicates: 0 Warnings: 0 mysql> ALTER TABLE book ADD UNIQUE vid (vid); ERROR 1062: Duplicate entry '0' for key 2 mysql> ALTER TABLE forum ADD UNIQUE vid (vid); Query OK, 10806 rows affected (0.10 sec) Records: 10806 Duplicates: 0 Warnings: 0 As you can see, it fails for the book table which makes me believe there is some inconsistent data ... I set out to fix that: mysql> SELECT nid, COUNT(nid) AS vids FROM book GROUP BY vid HAVING vids > 1; +-----+------+ | nid | vids | +-----+------+ | 871 | 2 | +-----+------+ 1 row in set (0.00 sec) mysql> SELECT title FROM node WHERE nid = 871; Empty set (0.00 sec) mysql> DELETE FROM book WHERE nid = 871; Query OK, 1 row affected (0.00 sec) mysql> ALTER TABLE book ADD UNIQUE vid (vid); Query OK, 368 rows affected (0.01 sec) Records: 368 Duplicates: 0 Warnings: 0 Looks like everything is well now. Ran some new benchmarks: Before upgrade After upgrade With indices ?q= (main page) 218 ms/request 340 ms/request 336 ms/request ?q=forum (forum overview) 754 ms/request 1520 ms/request 1531 ms/request ?q=about (book page) 375 ms/request 5400 ms/request 475 ms/request Unfortunately, we're still slower than the original code. ------------------------------------------------------------------------ May 18, 2005 - 23:53 : killes(a)www.drop.org Dries, thanks for testing it again. I do think the broken queries you observer have something to do with the bad performance after the update. Please log the queries any I will have a look at them. I've never seen any such queries. My update script also tries to create the appropriate indices, but it will of course fail if the database contains cruft. the indices for the forum are probably missing, too. I am still convinced that the patch is core worthy. ------------------------------------------------------------------------ May 19, 2005 - 06:36 : Dries It wouldn't hurt if more people would benchmark this patch. The patch's current performance worries me. Did you check your watchdog messages after upgrading the drupal.org database? Depending on your settings, errors might only be shown in the watchdog. I'll look into the remaining glitches as time permits. Thanks for your persistence in keeping this patch up-to-date. :)

1 0

[drupal-devel] [bug] Put revisions in their own table
by Dries 19 May '05

19 May '05

Issue status update for http://drupal.org/node/7582 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: Dries Status: patch It wouldn't hurt if more people would benchmark this patch. The patch's current performance worries me. Did you check your watchdog messages after upgrading the drupal.org database? Depending on your settings, errors might only be shown in the watchdog. I'll look into the remaining glitches as time permits. Thanks for your persistence in keeping this patch up-to-date. :) Dries Previous comments: ------------------------------------------------------------------------ May 5, 2004 - 18:25 : killes(a)www.drop.org Currently all node revisions are stored in a serialized field in node.table and retrieved for _each_ page view although they are rarely needed. However, we have agreed that serializing data is bad and that we should try to keep the memory foot print pf Drupal small. Therefore I propose to create a separate revisions table which would be in principle identical to the node table, only that it could have several old copies of the same node. Extra data added by other modules could be added in a serialized field unless we find a better solution. ------------------------------------------------------------------------ May 5, 2004 - 19:06 : jhriggs I too think the serialized approach is less than desirable, but here's an alternative. This would likely take some considerable rework in core and contrib, but the following is how we handle similar types of situations in our databases at work. It is more elegant that a separate table, and avoids the (almost exact) duplication of a table. Instead of separate tables, keep all revisions of nodes in the node table as follows: * add field: active (0/1 or Y/N) * add field: revision * every revision of a node is stored in the node table; however, only one revision can be active at any given time * nid can no longer be unique -- primary/unique key becomes (nid, active) * any time a node is loaded, updated (without revision), etc., the active version is used. Thoughts? ------------------------------------------------------------------------ May 5, 2004 - 19:57 : killes(a)www.drop.org I am not opposed to your scheme, but I want to stress the following: * Duplicating a table's structure is not bad (IMHO) as long as the content is different. * having two tables will allow us to have a rather small node table. This is (maybe) a performance gain. ------------------------------------------------------------------------ May 5, 2004 - 20:37 : jhriggs I don't necessarily think that duplicating a table's structure is _bad_. It just seems to be wasteful and a pain to maintain. (Every change to the node table is made twice...easy to do, but also easy to miss perhaps.) As for performance, as long as nid and the active indicator are indexed, there shouldn't be any performance loss. Also, archiving an old version when making a new revision will be much simpler: just change the active indicator rather than copying an entire node to another table (and ensuring everything gets copied...again a potential maintainance issue). To be honest, I would just like to see the serialized data go away, regarless of what approach is taken. ------------------------------------------------------------------------ July 30, 2004 - 21:49 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_07-30-2004.p… (10.47 KB) I'm interested in using Drupal for a large scale wiki-type project. In order to do this, I need revisions to be in their own table. Attached is a patch to do just that. Most of the changes are pretty self explanatory. Spreading out node data across two tables meant that I had to add database functions to do locking/transactions. Without this, race conditions in which the database becomes corrupted are possible. ------------------------------------------------------------------------ July 30, 2004 - 21:54 : Nick Nassar Oh yeah... The patch is a diff against Drupal CVS ------------------------------------------------------------------------ July 31, 2004 - 02:00 : Anonymous Gerhard speaking. Nick, thanks a lot for your nice patch! It saves me a great deal of labour. I looked through it and immediately liked it. You not only put the old revisions into a new table but also the current one. Do you have an estimate how much more expensive the additional join is? Besides a few minor coding style issues I found a major one: Just a few hours before you uploaded your patch JonBob's node access patch hit core. That means your patch won't apply anymore as all the queries you change have been changed. Can I bug you to update your patch? ------------------------------------------------------------------------ July 31, 2004 - 03:11 : Anonymous Also I think that your upgrade path loses existing revisions. ------------------------------------------------------------------------ July 31, 2004 - 04:39 : drumm I think this is the proper way to do things. No columns are duplicated, there is no serialized data, and only the fields that are logically revised are stored. Nothing jumped out at me as a way to have my node modules be able to keep a table of revisions of additional fields. I'm guessing this could be done within the confines of _insert and _update. Assuming the upgrade path works and modules can extend it I give it a +1. ------------------------------------------------------------------------ July 31, 2004 - 16:40 : Nick Nassar It figures that just as I finish a big patch, another patch comes along and breaks it. Oh well, it should be a pretty easy to fix. I'll work on it. Fixing the upgrade path to keep revisions should be fairly painless. I found another issue that needs to be fixed before this patch gets merged. There format of a node needs to be stored for each revision. Otherwise, for modules that store a format for the nodes, such as page and book, if you write one revision in PHP and the next in HTML, the PHP revision will be displayed as HTML. This is part of a larger issue of how node modules should store revisions of additional fields. I think each module that wants to do this should create another table with (nid, revid) as the primary key. Just as when they want to add fields to a node they create another table with nid as the primary key. As far as performance goes, for sites that make heavy use of revisions, an extra join on primary keys is going to be a lot faster than grabbing all of the revisions from that database everytime. We would need to run benchmarks to determine is the overall difference in speed is for an average site is a gain or a loss. I'm guessing it's very minor either way. ------------------------------------------------------------------------ August 23, 2004 - 15:55 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_08-23-2004.p… (10.92 KB) Here's an updated patch against CVS that puts revisions in their own table, provides an upgrade path, and fixes the format related bugs in the last patch. Hopefully, this can make it into CVS as soon as the freeze is over. ------------------------------------------------------------------------ August 23, 2004 - 16:10 : moshe weitzman Interesting patch ... drumm's question is still outstanding. how do modules store revisions of their fields? Are they expected to manage this on their own? Thats not how it works today. As an aside, i am seeing profile_ fields in my node.revisions column. One could argue that those need not be saved. They pertain to the node author, not to the node itself. ------------------------------------------------------------------------ August 23, 2004 - 18:14 : Nick Nassar Having modules be responsible for storing revisions of their own fields is a side-effect of storing revision data in tables. There's really no way around it. However, revisions generally don't make sense for node types that don't have PHP/HTML content, such as polls. I think it's going to be a pretty rare scenario for a new node type to want another field to change per-revision, so it's a pretty good trade-off. Storing fields that shouldn't be part of revisions, such as the profile_ fields, is a side-effect of storing revisions as serialized objects. Applying this patch will free up that wasted space. :) ------------------------------------------------------------------------ August 23, 2004 - 19:20 : Anonymous There should be a hook that let's the module choose whether it supports history. This way a module author can prevent the user from doing something that may break his module or just cause undefined behavior. If the module doesn't support history then don't let the user/admin choose to add history to nodes of that type. Craig ------------------------------------------------------------------------ August 23, 2004 - 21:23 : Nick Nassar I agree, there should be an API change to make specifying support for revisions easier. In the interests of keeping patches small and keeping to one change per patch, I think the API change should be a separate issue. A sort of ad-hoc API to decide whether or not a module supports revisions by default already exists. Instead of having a hook, modules set the default value of the "Create new revision" field in the edit form. The admin can change this option in admin/node/configure/defaults. This patch doesn't change that. Revisions are broken for node types that have their own database structure, like polls, even when storing them as serialized objects. This patch doesn't change that, either. ------------------------------------------------------------------------ October 26, 2004 - 04:35 : moshe weitzman I'm guessing that someone is going to have to demonstrate that this patch performs as well as current drupal before it gets comitted. i think this patch is a few benchmarks from being comitted. ------------------------------------------------------------------------ October 27, 2004 - 03:04 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004.p… (11 KB) I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ October 27, 2004 - 03:05 : Nick Nassar I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ October 27, 2004 - 03:05 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004.p… (11 KB) I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ November 15, 2004 - 07:05 : elias1884 please overthink the revision system default workflow as well. don't look at the revision system as an isolated system but as a part of the whole workflow system! if you combine revisions with the moderation queue the most logic default workflow would be like that: auth user creates node (revision #0) admin approves the node (status = 1, moderation = 0) => node publicly available auth user finds typo and changes node (revision #1, status = 0, moderation = 1) ------- what happens at that point at the moment is, that the node is not accessible anymore at all until the new revision is approved by admin. of course the new revision should not go online until reviewed and approved, this is absolutely correct, but there is no reason to not take the old revision offline, since it was already approved and should therefore be online until the new revision is approved. it is not practical if a node disappears only because the author corrected a typo. ------- admin approves the node (status = 1, moderation = 0) eventhough I first thought a plain boolean active field would not be capable of providing that functionality if finally came to the conclusion, that it can. The only thing to do is to not set that bit, when a new revision is created, but when it is approved (in case moderation is activated under default workflow). Every revision should have its own moderation, status and active field and on approval they are set like this (status=1, moderation=0, active=Y). When you wanna rollback to an old revision, you can chose between all revisions that already have the moderation bit set back to 0 again and the published to 1. There should be an extra permission for rollback! another concern that I have about the default workflow is, that users can't see the content, they have just created, when moderation is enabled. Eventhough, there is a big fat "submission accepted" presented after submissions, unexperienced users tend to question the information those stupid tincans give them, if they can't find their content afterwards. Many users are really lazy bastards and they don't even read the status messages. The best feedback about whether his story was submitted successfully or not of course is, if he can find the story somewhere on the site, maybe with a status message on top of it, mentioning, that the content is currently not publicly available since it has not been approved yet. there should be a my content section under my account, like somebody is trying to do with the workspace module I guess. so my suggestion is to make (status=0, moderation=1) still available for the creator under a my content section somewhere! ------------------------------------------------------------------------ November 24, 2004 - 06:21 : Nick Nassar I agree. The current workflow for moderation queues and revisions needs to change, but this patch isn't the place for it. The patch is already too big, and it only does the backend stuff. Instead of adding more to this patch and making it take even longer to get into core, would you mind creating a new issue for your UI suggestions, so the those changes can be added as a separate patch? Thanks, Nick ------------------------------------------------------------------------ December 11, 2004 - 14:26 : Dries This patch is _much_ needed so I'd love to see someone revive it. In order for this patch to be accepted, the following needs to be done: Update this patch to CVS HEAD. Rename revid to vid. Rename node_rev to node_revisions. Rename node_rev.changed to node_revisions.timestamp. Rename $rnode to $revision. Fix the coding style to match Drupal's: proper spacing, single quotes where possible, proper variable names. Benchmark this patch with a large database with enough revisions. I'd be happy to benchmark this on my local copy of the drupal.org database. The book.log field should probably move to the node_revisions table. This can be done in a separate patch. Investigate whether transactions are well-supported. ------------------------------------------------------------------------ December 13, 2004 - 02:25 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004-r… (11.02 KB) I've worked a bit on the patch (coding style issues as mentioned by Dries). One thing I noticed is that the patch uses REPLACE. IIRC this needs to be chagned to "UPDATE, if fail INSERT" for pgsql compatibility. Nick, are you still interested in working on that patch? I'd like to know how it works on your site and work on getting it into core. ------------------------------------------------------------------------ December 13, 2004 - 14:33 : Dries Gerhard: your patch does not apply. ------------------------------------------------------------------------ December 13, 2004 - 19:10 : killes(a)www.drop.org Yes, I know, that was the same version as I mailed to you earlier. ------------------------------------------------------------------------ December 13, 2004 - 23:02 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions.patch (52.96 KB) Ok, upüdated the patch to cvs. ------------------------------------------------------------------------ December 14, 2004 - 10:58 : Dries Some more comments: db_begin_transaction() and db_end_transaction() do not belong in database.inc, but in database.mysql.inc and database.pgsql.inc respectively. The node module calls node_revisionsision_list() which is not defined. (Fxed that on my local copy.) Do db_begin_transaction() and db_end_transaction() deprecate Jeremy's table locking patch? The upgrade path assigns the wrong user ID to each revision. The upgrade path assigns the wrong date to each revision (that or a node's revision page shows the wrong usernames/dates). The coding style needs a bit of work, but we can worry about that later. ------------------------------------------------------------------------ December 14, 2004 - 19:34 : Nick Nassar If you need any help getting those things fixed, just let me know. ------------------------------------------------------------------------ December 14, 2004 - 19:50 : Nick Nassar How this relates to Jeremy's node locking patch: There was lots of discussion, and node locking was decided against because from an end user point of view you never want a node to be locked. He's now advocating for a much simpler patch that warns users if their changes will overwrite someone elses. That patch still has a race condition, which might be fixed using db_begin_transaction(). http://drupal.org/node/6025 ------------------------------------------------------------------------ December 15, 2004 - 00:26 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_0.patch (55.96 KB) Here is an updated patch that tries to address Dries concerns. ------------------------------------------------------------------------ December 15, 2004 - 10:32 : Dries Attachment: http://drupal.org/files/issues/revisions-bug.png (76.06 KB) It didn't fix the aforementioned bugs. See attached screenshot. ------------------------------------------------------------------------ January 6, 2005 - 22:15 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_1.patch (51.77 KB) Ok, here is a new version. Dries and myself worked hart at it, so please have a look. what is still missing - database upgrades for the core modules with an own table - contrib modules need an upgrade too. - do we need nid and vid in both the node and the node_revisions table? - the amount of sql queries means a good stress testing for large databases. ------------------------------------------------------------------------ January 19, 2005 - 23:43 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_2.patch (49.49 KB) Here is an updated patch. We discussed to keep the current title in node module and also in the revisiosn table. This is content duplication but will save many joins as many queries only need the title of a node. Discussion is welcome. ------------------------------------------------------------------------ January 20, 2005 - 01:33 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_3.patch (29.93 KB) I've implemented the aforementioned solution. This makes the patch much smaller. The patch now also removes taxonomy_node_has_term() which wasn't used anywhere. I'd really apprciate if some people could test drive the patch. It will be another huge improvement for 4.6. ------------------------------------------------------------------------ January 20, 2005 - 02:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_4.patch (30 KB) Another revision. Steven didn't like my literal $node->vid in queries. ------------------------------------------------------------------------ January 20, 2005 - 03:10 : killes(a)www.drop.org - database upgrades for the core modules with an own table - contrib modules need an upgrade too. - do we need nid and vid in both the node and the node_revisions table? - the amount of sql queries means a good stress testing for large databases. These issues are still open, btw. Especially the first one needs to be tackled. ------------------------------------------------------------------------ January 25, 2005 - 22:11 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_5.patch (51.13 KB) Here is a patch that has the database tables updated for forum, book, and page module. ------------------------------------------------------------------------ January 30, 2005 - 00:55 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_6.patch (49.18 KB) Yet another update to keep it working with head. The patch now also removes the table definitons for the page table. ------------------------------------------------------------------------ January 30, 2005 - 00:57 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_7.patch (55.69 KB) Sorry, that was the old version, this is the right one. ------------------------------------------------------------------------ January 31, 2005 - 21:55 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_8.patch (55.71 KB) Updated once more. ------------------------------------------------------------------------ January 31, 2005 - 22:52 : Dries Anyone to help review/test this? ------------------------------------------------------------------------ January 31, 2005 - 23:22 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_9.patch (49.29 KB) Updated again, the update functions occurred twice. Thanks Bart. ------------------------------------------------------------------------ February 2, 2005 - 02:27 : killes(a)www.drop.org Don't know if the db I am using is corrupted or what. I still do have some didficulties. The latest patch is attached. ------------------------------------------------------------------------ February 2, 2005 - 02:27 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_10.patch (49.67 KB) I am probably slowly going mad ... ------------------------------------------------------------------------ February 2, 2005 - 03:54 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_11.patch (48.95 KB) The update issue still needs investigating. This patch is updated for cvs. ------------------------------------------------------------------------ February 2, 2005 - 22:20 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_12.patch (49.83 KB) Ok, here is a new version. I've solved my troubles with book.module. There are still some issues with forum module. Possibly due to inconsistent database. ------------------------------------------------------------------------ February 2, 2005 - 23:31 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_13.patch (49.83 KB) Turns out the drupal.org database had indeed some quirks. Please run this query in your oldest db and tell me the result: select nid,type from node where type like '%/%'; If you get a non-zero result we might need to add another security update. The patch could use still more testing, though. ------------------------------------------------------------------------ February 3, 2005 - 03:16 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_14.patch (49 KB) Ok, we are getting somewhere. At a first glance the update is working. There is a problem remaining: the revisions tab will be shown whether the node has revisions or not. Not sure we can/need to fix this. People with a drupal.org account can log in at http://killes.drupaldevs.org/revision/ and poke around. Your permissions will be the same as on drupal.org. Feel free to vreak everything but don't forget to file complaints here. (Note: this is only a pruned version of the drupal.org database with all project nodes and nodes with nids > 7000 dropped). ------------------------------------------------------------------------ February 3, 2005 - 06:19 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_15.patch (52.39 KB) There was some error in node_save and also the patches to the database.inc files got lost... ------------------------------------------------------------------------ February 3, 2005 - 09:07 : robertDouglass Submitting book pages doesn't work on your test site. It puts the entire content of the preview inside the body textarea. I wrote a sentence in the body and the log, and pressing preview put several lines of HTML containing both sentences in the body textarea on the preview page, plus the book page wouldn't submit. -R ------------------------------------------------------------------------ February 3, 2005 - 09:50 : Junyor 0 results here. I started using Drupal with version 4.4, though. ------------------------------------------------------------------------ February 4, 2005 - 01:56 : killes(a)www.drop.org @Junyor: Thanks, that's a good sign. Maybe somebody else has an older db to try. @robertDouglass: The first effect you describe is due to drupaldevs running on PHP 5. I am unsure why the second thing does not work. In node_save() the node object has a nid although there is none in the form. Very strange. I've enabled display of db queries on the testsite. ------------------------------------------------------------------------ February 4, 2005 - 21:17 : dmjossel No results here on the query: select nid,type from node where type like '%/%'; On a database that was put in place prior to Drupal 4 and is now running on 4.5.2. ------------------------------------------------------------------------ February 4, 2005 - 22:44 : killes(a)www.drop.org @dmjossel: thanks. @all. The strange problem I reported was apparently php 5 related. After applying Steven's php 5 patch it went away. One error is remaining: If I create a new forum topic it will be shown as part of the book on preview. Hmm, that was due to a db that got corrupted during testing so that is fixed too. Please poke around at the test site and look if you find more errors. ------------------------------------------------------------------------ February 5, 2005 - 09:16 : Steven By the way, I just remembered that Drupal.org has some blogs lingering on in the database even though blog.module is not enabled. Perhaps this is causing troubles? ------------------------------------------------------------------------ February 5, 2005 - 13:22 : Anonymous I can't see why it would. Drupal.org will need extra updates for images and project nodes because those have their own tables. GK. ------------------------------------------------------------------------ February 6, 2005 - 14:49 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_16.patch (52.49 KB) Updated to apply to cvs again. ------------------------------------------------------------------------ February 22, 2005 - 22:15 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_17.patch (49.64 KB) Updated again. All we need is a patch to upload module and an upgrade path for it. ------------------------------------------------------------------------ March 4, 2005 - 06:22 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_18.patch (52.31 KB) Updated once more. Moved log field from book to node_revisions table as discussed in Antwerp. upload module still missing. We need to decide under which circumstances the log field should be displayed. Should that be added to the workflow? Should it depend on the revisions setting? ------------------------------------------------------------------------ March 5, 2005 - 21:27 : Anonymous Attachment: http://drupal.org/files/issues/revisions_20.patch (75.52 KB) Ok, here it is: Yet another revision of this grrrrreat patch. Changes from previous versions: - supports versioning for uploaded files. A problem is that if you delete a file, it will be gone for all revisions. - the log field is now in the node_revsions table, but each module has to decide whether to show it or not. I've implemented it for the page and the book type odes. Also, the field can be edited when adding non-book nodes to the book. The log is displayed on the revisions page and if a node is moderated. - the revisions are moved to an old_revisions table to a) get the node table smaller and b) still leave the mavailable for contrib modules that want to retreive old version data. The patch has been applied to killes.drupaldevs.org/revision where it can be tested by anybody (especially people who have "site admin" rights on drupal.org) The database is from drupal.org and you should b able to log in with your pass or simply mail yourself a new one. Gerhard ------------------------------------------------------------------------ March 5, 2005 - 21:51 : Anonymous Attachment: http://drupal.org/files/issues/revisions_21.patch (59.42 KB) BTW, I marked this a bug because atm the revisions field can grow quite big. Neil has reported problems from some users who were not able to load some nodes due to to many large revisions. Also, som unrelated stuff crept into the patch. New version attached. ------------------------------------------------------------------------ March 8, 2005 - 07:56 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_22.patch (60.29 KB) Ok, I think I got it. Changes to last version: - uploads are no properly versioned. Missing are still pgsql checks and updates. ------------------------------------------------------------------------ March 10, 2005 - 18:58 : Anonymous Was able to get http://drupal.org/files/issues/revisions_21.patch to work with drupal-cvs.tar.gz (10 March 2005) by: - includes/database.mysql.inc: Commenting out duplicates for functions function db_begin_transaction and function db_commit_transaction - modules: node.module: Removing "'title' => $node->title," from $node_table_values variable declaration and removing "'title' => "'%s'"," from "$node_table_types" variable declaration. Happy to submit a patch if requested. I'll watch this thread. ------------------------------------------------------------------------ March 12, 2005 - 01:59 : killes(a)www.drop.org The duplicate function has been removed in rev 22 of this patch. Why do you think the changes in node_save are needed? Titles are saved in both tables for performance reasons. ------------------------------------------------------------------------ March 13, 2005 - 18:12 : jlerner Hi - I posted comment #62. The changes to node_save appear to be needed because recent patches (both 21 and 22) remove the field 'title' from table 'node'. So without the changes to node_save, node.module is broken and generates errors. Joshua ------------------------------------------------------------------------ March 13, 2005 - 18:29 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_23.patch (61.17 KB) Thanks, Joshua, for catching this. node:title is there to stay. ------------------------------------------------------------------------ April 13, 2005 - 18:29 : moshe weitzman since HEAD is open again, perhaps it is a good time to revisit this patch. once this is committed, lets address - http://drupal.org/node/11071 "node_validate does not respect group editing" ------------------------------------------------------------------------ April 18, 2005 - 17:43 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_24.patch (60.39 KB) Updated. ------------------------------------------------------------------------ April 18, 2005 - 18:16 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_24_0.patch (60.39 KB) Updated. ------------------------------------------------------------------------ April 19, 2005 - 07:19 : Dries I'll commit this patch later this week! If you haven't checked this patch already, I urge you to test/check it out because it will have significant impact on existing code and modules! ------------------------------------------------------------------------ April 19, 2005 - 07:21 : Dries Also, what do people think about the n.title being duplicated? ------------------------------------------------------------------------ April 19, 2005 - 07:26 : chx I won't lose any sleep because of duplicated titles... ------------------------------------------------------------------------ April 19, 2005 - 20:35 : killes(a)www.drop.org Let me explain why I have chosen to duplicate the title (and also the uid): If you look at all the queries in Drupal, you will find that most of them only need the title and th uid of a node. That is, by duplicating it, we save expensive joins on the node_revisions table. Due to this fact, this patch is actually a performance improvement. A note about updating contrib module: Strictly speaking they wouldn't need to be updated. They only need to if their authors decide that their info should be available for revisioning. The upgrade path for forum.module in my update.inc patch (+ the forum patch) should show you what needs to be done. I will write a note for the update page once the patch hits core. ------------------------------------------------------------------------ April 24, 2005 - 23:21 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_25.patch (60.38 KB) Updated to cvs. Dries: Based on some remarks in #drupal this is the last update I am going to do. Apply it or won't fix it. ------------------------------------------------------------------------ April 30, 2005 - 05:42 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/revisions_25.patch.patch (528 bytes) That's a big patch. I've only started looking through it. I noticed one little typo, affecting updates. A patch to your last patch is attached. I'm running with the revision patch on my dev server now happily. I like the concept. What happens if you click 'stop' on your browser in the middle of a MySQL "transaction"? I assume that kills the connection to MySQL, and the lock is freed? But this then leaves changes only partially applied? What exactly does locking/unlocking the tables buy us in MySQL? I don't see anywhere that we detect if an apply fails part way through, and thus roll back...? What am I missing? ------------------------------------------------------------------------ April 30, 2005 - 09:11 : Dries Jeremy: many of us are worried about the performance ramifications this patch introduces. Early experiments showed a small performance improvement (while a performance regression might be expected). More performance reports from large sites like kerneltrap.org will certainly help this patch. Mind to do a quick performance comparision and to report back with some numbers? Thanks. ------------------------------------------------------------------------ April 30, 2005 - 14:38 : Jeremy(a)kerneltrap.org Dries: I'm not running HEAD on kerneltrap, so this really isn't a possibility. Furthermore, until I understand why we're locking tables, I don't like it. The idea of revisions in their own tables is great. The idea of locking tables to get (without any obvious benefit) there really worries me. ------------------------------------------------------------------------ April 30, 2005 - 16:16 : killes(a)www.drop.org @Jeremy: Thanks for looking at the patch! Also for catching the typo. :) Did you try to upgrade your database? If yes, how did it go? One of Dries' concerns is the complexity of the upgrade. How many nodes and revisions did the db have? About database locking: This part of the patch was created by Nick and I simply continued to use it. Maybe the code should rather be: if(db_begin_transaction(array('{node}', '{node_revisions}', '{watchdog}', '{sessions}', '{files}'))) { db_query($node_query, $node_table_values); db_query($revisions_query, $revisions_table_values); db_commit_transaction(); ... } The idea is probably to avoid two updates at the same time. I don't think the locking helps if you abort the script at an inconvenient time. Rollbacks aren't implemented in all mysql versions. We could omit the db locking if deemed inappropriate. Maybe Nick can explain his ideas behind this. @Dries: I wonder who the "many of us" are. They certainly haven't spoken to me. Moshe had some reservations about the upgrade path and project module, but the time that project module abused revisions to store issue updates was long ago and his reservations were resolved. Nobody else (besides you of course and now Jeremy) has voiced reservations in a way that was audible to me. If you grep through the patch you will notice that there are only four queries which have a join on the node_revisions table. Two of them are in node_load and in the other cases the join replaced a join on the node table. The two queries in node_load are the only ones that have both a join on the node and the revisions query. Thus, loading of individual nodes might become somewhat slower. All other queries will be faster since the node table is now much smaller. Also, node loading does not have to be slower, it depends on your node table. If you had a lot of revisions and thus a large table, then the new scheme will make your queries actually faster since we do not load the revisions on each and every node load anymore. If you didn't have many revisions your node_load migth be somewhat slower. WRT to the update script Karoly pointed out that we could use multiple insert queries instead one query per revision. This would probably make the update somewhat faster. I am willing to work on this iff you declare that you will commit the patch afterwards. I'd need to know if this will work on pgsql and on all supported mysql versions before I work on it. About locking: Database locking is dog slow, at least on mysql. I was using locks in an earlier version of the upgrade script but had to remove it for (serious!) performance reasons. ------------------------------------------------------------------------ May 9, 2005 - 17:07 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_26.patch (46.45 KB) Ok, another update, cause I need it myself. I've left out the transaction stuff for now. It is in principle unrelated to this patch and should be discussed elsewhere. This also makes the patch smaller and easier to review (hint, hint). ------------------------------------------------------------------------ May 9, 2005 - 22:32 : killes(a)www.drop.org The patch contained the update functions twice. ------------------------------------------------------------------------ May 9, 2005 - 22:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_27.patch (39.05 KB) The patch contained the update functions twice. ------------------------------------------------------------------------ May 9, 2005 - 23:23 : Dries Got one error during the upgrade path: ALTER TABLE {book} ADD PRIMARY KEY vid (vid) FAILED ------------------------------------------------------------------------ May 9, 2005 - 23:26 : killes(a)www.drop.org This had happend to me as well, when I tested this patch. The reason is that for some reason the vid is not unique. Most likely there are some entries with vid = 0 in there. Can you check which node types those have? it always was an error in the test database. See: http://drupal.org/node/7582#comment-20678 ------------------------------------------------------------------------ May 9, 2005 - 23:27 : Dries Actually, I got 2850 errors during the upgrade. Some of these: sprintf() [function.sprintf]: Too few arguments in drupal-cvs/includes/database.inc on line 154. Some of these: Query was empty query: in drupal-cvs/includes/database.mysql.inc on line 66. And this: Unknown table 'n' in field list query: SELECT n.nid, n.vid FROM node INNER JOIN files f ON n.nid = f.nid in drupal-cvs/includes/database.mysql.inc on line 66. :-) ------------------------------------------------------------------------ May 9, 2005 - 23:29 : Dries Or this: user error: Unknown column 'log' in 'field list' query: SELECT parent, weight, log FROM book WHERE nid = 1 in drupal-cvs/includes/database.mysql.inc on line 66 ------------------------------------------------------------------------ May 9, 2005 - 23:52 : Dries The time required to generate my main page went from 902 ms (before upgrade) to 2139 ms (after upgrade). The time required to generate a forum listing (?q=forum/x) went from 1872 ms (before upgrade) to 2874 ms (after upgrade). Maybe this is because my database is not consistent as the result of the upgrade errors (yet I don't see any errors on the pages I benchmarked). ------------------------------------------------------------------------ May 10, 2005 - 02:24 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_28.patch (53.47 KB) Ok, let me get to this from the bottom to the top: - my test runs indicated a different development wrt timing. If I had gotten your results, I had stopped working on this long ago. So your results are wrong for some reason. - user error: Unknown column 'log' in 'field list' Wasn't my day, the book patch got lost. It is contained now. First -R the old patch, then apply this one. - Unknown table 'n' in field list query: Walkah found this, but I forgot to fix it. Fixed now. - I've no idea where the other queries come from. I am hoping that either your test db is borken or they are follow ups from the other ones. If you let me have your test db, I'll try some debugging. Thanks for wasting your time, too. ------------------------------------------------------------------------ May 10, 2005 - 07:07 : Dries I double-checked and the numbers don't seem to lie. I'll test some more after work on another machine to make sure it is not platform-specific. ------------------------------------------------------------------------ May 11, 2005 - 05:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_29.patch (54.83 KB) Ok, here I am again. What I did: 1) Ask Dries to let me have drupal.org database 2) get 400MB of SQL inserts... 3) take 23 minutes to import said data 4) Remove all image and project nodes (don't want to install their modules), 11765 nodes left 5) back up data 6) take tests on non-cached /node page (as anonymous user). ab results: -c 1 -n 25: Requests per second: 1.29 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 663 775 179.7 689 1264 7) Do the same for the tracker page: Requests per second: 0.83 [#/sec] (mean) Total: 1182 1199 7.4 1199 1217 8) Apply my patch (rev. 28). 9) run db update and hold breath 10) update times out... 11) play back backup from 5) 12) wait 13) getting annoyed and removing cache, watchdog, and accesslog before playing in backup. 14) wait again. Understand why Dries doesn't try this patch often. Maybe a smaller DB would do for testing? 15) wait more. get really annoyed. 16) Set time limit to 18000 in update.php 17) try again 18) fails again before the second update is completed. 19) curse. 20) delete search stuff from db. Ooops, sooo much smaller... 21) import again, below 2 minutes... 22) rewrite to use extended insert. Found a bug. 23) still does not complete. Mysql logging to the rescue! 24) tid = 0? Not good. 25) Well, the update works fine till node 10834. 5595 nodes done, 6136 to go. 26) Writing shell based update script. Discovery: 24MB aren't enough. Hopefully 64 are. Nope. extended inserts for revisions are apparently not the brightest idea: Huge memory consumption. Hmm, no, all updates got through. Selecting the revisions to put them into old_revisions table screwed it. Learned about CREATE TABLE old_revisions SELECT syntax. Yay! finally. 24 MB are just not enough the update.php script seems to still break. 27) Benchmarks! /node Requests per second: 1.54 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 632 649 40.5 636 791 /tracker Requests per second: 0.86 [#/sec] (mean) Total: 1119 1165 65.8 1160 1461 Ok: So we get an improvement for many node_loads, but none for simple selects from node. More tests can be done. 28) roll new patch Ain't Drupal fun? ------------------------------------------------------------------------ May 18, 2005 - 15:38 : Dries I did another round of tests on _another_ machine and it is not looking good: Before upgrade After upgrade ?q= (main page) 218 ms/request 340 ms/request ?q=forum (forum overview) 754 ms/request 1520 ms/request ?q=about (book page) 375 ms/request 5400 ms/request The upgrade process itself gave me a number of 'query was empty' and 'sprintf(): too few arguments' reports. Everything seems to work fine though. Looking at the ?q=about page, I see that the following query is executed twice _and_ that each time, it take more than 2 seconds to complete: SELECT n.nid, n.title, b.parent, b.weight FROM node n INNER JOIN book b ON n.vid = b.vid WHERE n.status = 1 AND n.moderate = 0 ORDER BY b.weight, n.title; --8 SHOW INDEX FROM book; +-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | book | 1 | book_parent | 1 | parent | A | 92 | NULL | NULL | | BTREE | | | book | 1 | nid | 1 | nid | A | 369 | NULL | NULL | | BTREE | | +-------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 2 rows in set (0.00 sec) The book module does not appear to have a primary key? Sounds like a bad idea so I added one: mysql> ALTER TABLE book ADD PRIMARY KEY nid (nid); Query OK, 369 rows affected (0.02 sec) Records: 369 Duplicates: 0 Warnings: 0 Next, I wanted to make the vid column a unique key in all node tables: mysql> ALTER TABLE node ADD UNIQUE vid (vid); Query OK, 20392 rows affected (0.81 sec) Records: 20392 Duplicates: 0 Warnings: 0 mysql> ALTER TABLE book ADD UNIQUE vid (vid); ERROR 1062: Duplicate entry '0' for key 2 mysql> ALTER TABLE forum ADD UNIQUE vid (vid); Query OK, 10806 rows affected (0.10 sec) Records: 10806 Duplicates: 0 Warnings: 0 As you can see, it fails for the book table which makes me believe there is some inconsistent data ... I set out to fix that: mysql> SELECT nid, COUNT(nid) AS vids FROM book GROUP BY vid HAVING vids > 1; +-----+------+ | nid | vids | +-----+------+ | 871 | 2 | +-----+------+ 1 row in set (0.00 sec) mysql> SELECT title FROM node WHERE nid = 871; Empty set (0.00 sec) mysql> DELETE FROM book WHERE nid = 871; Query OK, 1 row affected (0.00 sec) mysql> ALTER TABLE book ADD UNIQUE vid (vid); Query OK, 368 rows affected (0.01 sec) Records: 368 Duplicates: 0 Warnings: 0 Looks like everything is well now. Ran some new benchmarks: Before upgrade After upgrade With indices ?q= (main page) 218 ms/request 340 ms/request 336 ms/request ?q=forum (forum overview) 754 ms/request 1520 ms/request 1531 ms/request ?q=about (book page) 375 ms/request 5400 ms/request 475 ms/request Unfortunately, we're still slower than the original code. ------------------------------------------------------------------------ May 18, 2005 - 23:53 : killes(a)www.drop.org Dries, thanks for testing it again. I do think the broken queries you observer have something to do with the bad performance after the update. Please log the queries any I will have a look at them. I've never seen any such queries. My update script also tries to create the appropriate indices, but it will of course fail if the database contains cruft. the indices for the forum are probably missing, too. I am still convinced that the patch is core worthy.

1 0