view doc/implementation.txt @ 5525:bb7865241f8a

Make CSV import/export compatible across Python versions (also RDBMS journals) (issue 2550976, issue 2550975). The roundup-admin export and import commands are used for migrating between different database backends. It is desirable that they should be usable also for migrations between Python 2 and Python 3, and in some cases (e.g. with the anydbm backend) this may be required. To be usable for such migrations, the format of the generated CSV files needs to be stable, meaning the same as currently used with Python 2. The export process uses repr() to produce the fields in the CSV files and eval() to convert them back to Python data structures. repr() of strings with non-ASCII characters produces different results for Python 2 and Python 3. This patch adds repr_export and eval_import functions to roundup/anypy/strings.py which provide the required operations that are just repr() and eval() in Python 2, but are more complicated in Python 3 to use data representations compatible with Python 2. These functions are then used in the required places for export and import. repr() and eval() are also used in storing the dict of changed values in the journal for the RDBMS backends. It is similarly desirable that the database be compatible between Python 2 and Python 3, so that export and import do not need to be used for a migration between Python versions for non-anydbm back ends. Thus, this patch changes rdbms_common.py in the places involved in storing journals in the database, not just in those involved in import/export. Given this patch, import/export with non-ASCII characters appear based on some limited testing to work across Python versions, and an instance using the sqlite backend appears to be compatible between Python versions without needing import/export, *if* the sessions/otks databases (which use anydbm) are deleted when changing Python version.
author Joseph Myers <jsm@polyomino.org.uk>
date Sun, 02 Sep 2018 23:48:04 +0000
parents 33a1f03b9de0
children 9ca128103a3a
line wrap: on
line source

====================
Implementation notes
====================

[see also the roundup package docstring]

There have been some modifications to the spec. I've marked these in the
source with 'XXX' comments when I remember to.

In short:
 Class.find() - may match multiple properties, uses keyword args.

 Class.filter() - isn't in the spec and it's very useful to have at the
    Class level.

 CGI interface index view specifier layout part - lose the '+' from the
    sorting arguments (it's a reserved URL character ;). Just made no
    prefix mean ascending and '-' prefix descending.

 ItemClass - renamed to IssueClass to better match it only having one
    hypderdb class "issue". Allowing > 1 hyperdb class breaks the
    "superseder" multilink (since it can only link to one thing, and
    we'd want bugs to link to support and vice-versa).

 template - the call="link()" is handled by special-case mechanisms in
    my top-level CGI handler. In a nutshell, the handler looks for a
    method on itself called 'index%s' or 'item%s' where %s is a class.
    Most items pass on to the templating mechanism, but the file class
    _always_ does downloading. It'll probably stay this way too...

 template - call="link(property)" may be used to link "the current item"
    (from an index) - the link text is the property specified.

 template - added functions that I found very useful: List, History and
    Submit.

 template - items must specify the message lists, history, etc. Having
    them by default was sometimes not wanted.

 template - index view determines its default columns from the
    template's ``tal:condition="request/show/<property>"`` directives.

 template - menu() and field() look awfully similar now .... ;)

 roundup_admin.py - the command-line tool has a lot more commands at its
    disposal

-----------------

Back to `Table of Contents`_

.. _`Table of Contents`: index.html


Roundup Issue Tracker: http://roundup-tracker.org/