Mercurial > p > roundup > code
view doc/mysql.txt @ 6433:c1d3fbcdbfbd
issue2551142 - Import of retired node ... unique constraint failure.
Title: Import of retired node with username after active node fails
with unique constraint failure.
More fixes needed for mysql and postgresql.
mysql: add unique constraint for (keyvalue, __retired__) when
creating class in the database.
On schema change if class is changed, remove the unique
constraint too.
upgrade version of rdbms database from 5 to 6 to add constraint
to all version 5 databases that were created as version 5
and didn't get the unique constraint. Make no changes
on version 5 databases upgraded from version 4, the upgrade
process to 5 added the constraint. Make no changes
to other databases (sqlite, postgres) during upgrade from
version 5 to 6.
postgres: Handle the exception raised on unique constraint violation.
The exception invalidates the database connection so it
can't be used to recover from the exception.
Added two new database methods:
checkpoint_data - performs a db.commit under postgres
does nothing on other backends
restore_connection_on_error - does a db.rollback on
postgres, does nothing on other
backends
with the rollback() done on the connection I can use the
database connection to fixup the import that failed on the
unique constraint. This makes postgres slower but without the
commit after every imported object, the rollback will delete
all the entries done up to this point.
Trying to figure out how to make the caller do_import batch
and recover from this failure is beyond me.
Also dismissed having to process the export csv file before
importing. Pushing that onto a user just seems wrong. Also
since import/export isn't frequently done the lack of
surprise on having a failing import and reduced
load/frustration for the user seems worth it. Also the import
can be run in verbose mode where it prints out a row as it is
processed, so it may take a while, ut the user can get
feedback.
db_test-base.py: add test for upgrade from 5 to 6.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Thu, 10 Jun 2021 12:52:05 -0400 |
| parents | 81ae33038ec5 |
| children | fc9e16fe3991 |
line wrap: on
line source
.. index:: mysql; deployment notes ============= MySQL Backend ============= This notes detail the MySQL backend for the Roundup issue tracker. Prerequisites ============= To use MySQL as the backend for storing roundup data, you also need to install: 1. MySQL RDBMS 4.0.18 or higher - https://www.mysql.com/. Your MySQL installation MUST support InnoDB tables (or Berkeley DB (BDB) tables if you have no other choice). If you're running < 4.0.18 (but not <4.0) then you'll need to use BDB to pass all unit tests. Edit the ``roundup/backends/back_mysql.py`` file to enable DBD instead of InnoDB. 2. Python MySQL interface - https://pypi.org/project/mysqlclient/ Other Configuration =================== If you are indexing large documents (e.g attached file contents) using MySQL, you may need to increase the max_allowed_packet size. If you don't you can see the error:: 'MySql Server has gone away (2006)' To do this edit /etc/my.conf and change:: [mysqld] max_allowed_packet = 1M the 'max_allowed_packet' value from '1M' to '64M' or larger. Alternatively you can install an alternate indexer (whoosh, xapian etc.) and force the tracker to use it by setting the ``indexer`` setting in the tracker's ``config.ini``. This fix was supplied by telsch. See issue https://issues.roundup-tracker.org/issue2550743 for further info or if you are interested in developing a patch to roundup to help work around this issue. Running the MySQL tests ======================= Roundup tests expect an empty MySQL database. Two alternate ways to provide this: 1. If you have root permissions on the MySQL server, you can create the necessary database entries using the follwing SQL sequence. Use ``mysql`` on the command line to enter:: CREATE DATABASE rounduptest; USE rounduptest; GRANT ALL PRIVILEGES ON rounduptest.* TO rounduptest@localhost IDENTIFIED BY 'rounduptest'; FLUSH PRIVILEGES; 2. If your administrator has provided you with database connection info, see the config values in 'test/db_test_base.py' about which database connection, name and user will be used. The MySQL database should not contain any tables. Tests will not drop the database with existing data. Showing MySQL who's boss ======================== If things ever get to the point where that test database is totally hosed, just:: $ su - # /etc/init.d/mysql stop # rm -rf /var/lib/mysql/rounduptest # /etc/init.d/mysql start and all will be better (note that on some systems, ``mysql`` is spelt ``mysqld``).