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.

Roundup Issue Tracker
=====================

.. raw:: html

   <div class="release_info note">Download:
   <a href="https://pypi.org/project/roundup/">latest</a></div>

Roundup is a simple-to-use and -install issue-tracking system with
command-line, web and e-mail interfaces.  It is based on the winning
design from Ka-Ping Yee in the Software Carpentry "Track" design
competition.

The current stable version of Roundup is 2.0.0 which has quite a
comprehensive :doc:`feature set <docs/features>` compared to the last
stable release (v1.6.1). These features include:

   * Python 2 and Python 3 support
   * a new REST interface
   * updates to jinja2 templates including security improvements

For more information see the :doc:`design overview <docs/design>`, and
all the other :doc:`documentation <docs>`. Roundup has been deployed
for:

    * bug tracking and TODO list management (the classic installation)
    * customer help desk support (with a wizard for the phone answerers, linking to networking, 
      system and development issue trackers)
    * issue management for IETF working groups
    * sales lead tracking
    * conference paper submission and double-blind referee management
    * weblogging (well, almost :) 

...and so on. It's been designed with :doc:`flexibility
<docs/customizing>` in mind - it's not just another bug
tracker. Roundup ships with a *demo tracker* to play with - after
you've unpacked the source, just run "python demo.py" and load up the
URL it prints out!

Roundup was originally released as version 0.1.1 in late August, 2001. The first `change note`_ I wrote says:

    Needed a bug tracking system. Looked around. Tried to install many Perl-based systems, to no avail.
    Got tired of waiting for Roundup to be released. Had just finished major product project, so needed
    something different for a while. Roundup here I come... 

.. _`download`: https://pypi.org/project/roundup/
.. _`change note`: https://sourceforge.net/p/roundup/code/ci/tip/tree/CHANGES.txt
.. _`its own set of docs`: https://www.roundup-tracker.org/dev-docs/docs.html