Huutoanbui3@gmail.com
Toi chua nhan duoc mot khoan tien nao ca .neu nhu muon hop tac lau dai thi
xin mong la moi nguoi hay lam ciec theo mot cach thuc te .va dung doi hoi
nheu qua .xin cam on
Vào 19:03 Th 7, 09 thg 11 2019 <mediawiki-l-request@lists.wikimedia.org> ?ã
vi?t:
> Send MediaWiki-l mailing list submissions to
> mediawiki-l@lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> or, via email, send a message with subject or body 'help' to
> mediawiki-l-request@lists.wikimedia.org
>
> You can reach the person managing the list at
> mediawiki-l-owner@lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MediaWiki-l digest..."
>
>
> Today's Topics:
>
> 1. Re: [Cargo] table format for _pageData and _fileData (Yaron Koren)
> 2. GitHub's "Automated Security Fixes" have been disabled on the
> Wikimedia Org (Sam Reed)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 8 Nov 2019 11:00:38 -0500
> From: Yaron Koren <yaron@wikiworks.com>
> To: MediaWiki announcements and site admin list
> <mediawiki-l@lists.wikimedia.org>
> Subject: Re: [MediaWiki-l] [Cargo] table format for _pageData and
> _fileData
> Message-ID:
> <CAGmQEQFfb--cRyPLFZik63su2qM-Nk73+0jyT+hc=
> zOjf39C+w@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Jan,
>
> Oh, that's too bad. I didn't know that MyISAM doesn't support database
> clustering. (You might be the first person to run Cargo on a clustered
> database - it's good to know that it seems to be working, other than this
> one problem.)
>
> You're right that the MyISAM requirement is only for old database versions
> - the last version of MySQL that had this problem was 5.6, and that version
> came out in 2013, and will stop being supported in a little over a year. I
> could have added a new setting like
> $wgCargoUseMyISAMForTablesWithSearchtextFields, but that seemed like
> overkill, so I decided instead to just remove this code that forces the use
> of MyISAM. Hopefully there aren't too many people who (a) are using Cargo
> with MySQL <= 5.6 (or its MariaDB equivalent), (b) use InnoDB by default,
> (c) use the _pageData or _fileData tables, and (d) will recreate these
> tables in the future. If there are, they'll have to either manually re-add
> this code in, or update to a more recent DB version.
>
> Anyway, if you get the latest version of the Cargo code, and recreate these
> tables, the problems will hopefully be gone.
>
> -Yaron
>
> On Fri, Nov 8, 2019 at 6:52 AM Jan Böhme <jan@idea-sketch.com> wrote:
>
> > Hi,
> >
> > for our production system I’m using a MariaDB Galera cluster as RDMS
> > backend. Though there is a feature to enable (experimental) replication
> of
> > MyISAM tables, this doesn't play well with Cargo. Certain operations
> > involving _pageData tables caused the cluster to reach an inconsistent
> data
> > state, thus stopping replication and ultimately falling apart.
> >
> > I could isolate the cause to the following transaction (which is embedded
> > between two inserts for the same thing):
> >
> > BEGIN /* Wikimedia\Rdbms\Database::begin */
> > SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE
> > 'cargo\_\_staff\_\_NEXT'
> > SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE
> > 'cargo\_\_staff\_\_\_files'
> > DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo__staff` WHERE
> > `_pageID` = '273'
> > DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo___pageData`
> > WHERE `_pageID` = '273'
> > COMMIT /* Wikimedia\Rdbms\Database::commit */
> >
> > cargo__staff table being InnoDB, cargo___pageData being MyISAM.
> > Unfortunately this leads to the delete statement on the InnoDB table not
> > being replicated, while the delete on the MyISAM table is. Thus on the
> > following insert the row already exists, causing a unique key violation
> and
> > inconsistent cluster state.
> >
> > Is it really still necessary to use MyISAM for these tables? Full text
> > indices are available on InnoDB for quite some time now, so I’m wondering
> > whether this still needs to be supported or if it would be possible to
> make
> > both choices available.
> >
> >
> > Best: Jan.
> >
> >
> > --
> > idea-sketch
> >
> > Jan Böhme & Uwe Schützenmeister
> > Lößnitzstr. 14
> > 01097 Dresden
> >
> > www.idea-sketch.com <http://www.idea-sketch.com/>
> >
> > Tel.: +49 . (0)351 . 810 74 250
> > Mobil: +49 . (0)179 .53 41 641
> >
> > _______________________________________________
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> >
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 8 Nov 2019 18:42:37 -0700
> From: Sam Reed <reedy@wikimedia.org>
> To: wikitech-l@lists.wikimedia.org, mediawiki-l@lists.wikimedia.org
> Subject: [MediaWiki-l] GitHub's "Automated Security Fixes" have been
> disabled on the Wikimedia Org
> Message-ID:
> <CAOCnLWYP_A9ugC+q3U=
> mF70mFOhvWygdAea3ewxHdKoMCZEemg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Just a heads up that "Automated Security Fixes" have been disabled on the
> Wikimedia GitHub org. See [1]
>
> The reason for this is that it generates pull requests on non canonical
> repositories (ie where Gerrit is the default development location) that
> require developers to close them.
>
> If this is a feature you want on your repo generally, because you
> canonically develop on GitHub, you can re-enable these on your repo by
> clicking the "Security" tab, and then selecting "Automated Security Fixes"
> in the top right corner. See [2] for more info. If you do develop
> canonically in GitHub, please let us know at [3].
>
> Note, this doesn't affect the security alerts related to outdated packages
> etc in a repo.
>
> Thanks!
>
>
> Sam
>
> [1] https://phabricator.wikimedia.org/T237337
> [2]
>
> https://help.github.com/en/github/managing-security-vulnerabilities/configuring-automated-security-fixes
> [3] https://phabricator.wikimedia.org/T237470
> [4]
>
> https://help.github.com/en/github/managing-security-vulnerabilities/viewing-and-updating-vulnerable-dependencies-in-your-repository
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
> ------------------------------
>
> End of MediaWiki-l Digest, Vol 194, Issue 5
> *******************************************
>
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Toi chua nhan duoc mot khoan tien nao ca .neu nhu muon hop tac lau dai thi
xin mong la moi nguoi hay lam ciec theo mot cach thuc te .va dung doi hoi
nheu qua .xin cam on
Vào 19:03 Th 7, 09 thg 11 2019 <mediawiki-l-request@lists.wikimedia.org> ?ã
vi?t:
> Send MediaWiki-l mailing list submissions to
> mediawiki-l@lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> or, via email, send a message with subject or body 'help' to
> mediawiki-l-request@lists.wikimedia.org
>
> You can reach the person managing the list at
> mediawiki-l-owner@lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MediaWiki-l digest..."
>
>
> Today's Topics:
>
> 1. Re: [Cargo] table format for _pageData and _fileData (Yaron Koren)
> 2. GitHub's "Automated Security Fixes" have been disabled on the
> Wikimedia Org (Sam Reed)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 8 Nov 2019 11:00:38 -0500
> From: Yaron Koren <yaron@wikiworks.com>
> To: MediaWiki announcements and site admin list
> <mediawiki-l@lists.wikimedia.org>
> Subject: Re: [MediaWiki-l] [Cargo] table format for _pageData and
> _fileData
> Message-ID:
> <CAGmQEQFfb--cRyPLFZik63su2qM-Nk73+0jyT+hc=
> zOjf39C+w@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Jan,
>
> Oh, that's too bad. I didn't know that MyISAM doesn't support database
> clustering. (You might be the first person to run Cargo on a clustered
> database - it's good to know that it seems to be working, other than this
> one problem.)
>
> You're right that the MyISAM requirement is only for old database versions
> - the last version of MySQL that had this problem was 5.6, and that version
> came out in 2013, and will stop being supported in a little over a year. I
> could have added a new setting like
> $wgCargoUseMyISAMForTablesWithSearchtextFields, but that seemed like
> overkill, so I decided instead to just remove this code that forces the use
> of MyISAM. Hopefully there aren't too many people who (a) are using Cargo
> with MySQL <= 5.6 (or its MariaDB equivalent), (b) use InnoDB by default,
> (c) use the _pageData or _fileData tables, and (d) will recreate these
> tables in the future. If there are, they'll have to either manually re-add
> this code in, or update to a more recent DB version.
>
> Anyway, if you get the latest version of the Cargo code, and recreate these
> tables, the problems will hopefully be gone.
>
> -Yaron
>
> On Fri, Nov 8, 2019 at 6:52 AM Jan Böhme <jan@idea-sketch.com> wrote:
>
> > Hi,
> >
> > for our production system I’m using a MariaDB Galera cluster as RDMS
> > backend. Though there is a feature to enable (experimental) replication
> of
> > MyISAM tables, this doesn't play well with Cargo. Certain operations
> > involving _pageData tables caused the cluster to reach an inconsistent
> data
> > state, thus stopping replication and ultimately falling apart.
> >
> > I could isolate the cause to the following transaction (which is embedded
> > between two inserts for the same thing):
> >
> > BEGIN /* Wikimedia\Rdbms\Database::begin */
> > SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE
> > 'cargo\_\_staff\_\_NEXT'
> > SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE
> > 'cargo\_\_staff\_\_\_files'
> > DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo__staff` WHERE
> > `_pageID` = '273'
> > DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo___pageData`
> > WHERE `_pageID` = '273'
> > COMMIT /* Wikimedia\Rdbms\Database::commit */
> >
> > cargo__staff table being InnoDB, cargo___pageData being MyISAM.
> > Unfortunately this leads to the delete statement on the InnoDB table not
> > being replicated, while the delete on the MyISAM table is. Thus on the
> > following insert the row already exists, causing a unique key violation
> and
> > inconsistent cluster state.
> >
> > Is it really still necessary to use MyISAM for these tables? Full text
> > indices are available on InnoDB for quite some time now, so I’m wondering
> > whether this still needs to be supported or if it would be possible to
> make
> > both choices available.
> >
> >
> > Best: Jan.
> >
> >
> > --
> > idea-sketch
> >
> > Jan Böhme & Uwe Schützenmeister
> > Lößnitzstr. 14
> > 01097 Dresden
> >
> > www.idea-sketch.com <http://www.idea-sketch.com/>
> >
> > Tel.: +49 . (0)351 . 810 74 250
> > Mobil: +49 . (0)179 .53 41 641
> >
> > _______________________________________________
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> >
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 8 Nov 2019 18:42:37 -0700
> From: Sam Reed <reedy@wikimedia.org>
> To: wikitech-l@lists.wikimedia.org, mediawiki-l@lists.wikimedia.org
> Subject: [MediaWiki-l] GitHub's "Automated Security Fixes" have been
> disabled on the Wikimedia Org
> Message-ID:
> <CAOCnLWYP_A9ugC+q3U=
> mF70mFOhvWygdAea3ewxHdKoMCZEemg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Just a heads up that "Automated Security Fixes" have been disabled on the
> Wikimedia GitHub org. See [1]
>
> The reason for this is that it generates pull requests on non canonical
> repositories (ie where Gerrit is the default development location) that
> require developers to close them.
>
> If this is a feature you want on your repo generally, because you
> canonically develop on GitHub, you can re-enable these on your repo by
> clicking the "Security" tab, and then selecting "Automated Security Fixes"
> in the top right corner. See [2] for more info. If you do develop
> canonically in GitHub, please let us know at [3].
>
> Note, this doesn't affect the security alerts related to outdated packages
> etc in a repo.
>
> Thanks!
>
>
> Sam
>
> [1] https://phabricator.wikimedia.org/T237337
> [2]
>
> https://help.github.com/en/github/managing-security-vulnerabilities/configuring-automated-security-fixes
> [3] https://phabricator.wikimedia.org/T237470
> [4]
>
> https://help.github.com/en/github/managing-security-vulnerabilities/viewing-and-updating-vulnerable-dependencies-in-your-repository
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
> ------------------------------
>
> End of MediaWiki-l Digest, Vol 194, Issue 5
> *******************************************
>
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l