Mercurial > p > roundup > code
view doc/glossary.txt @ 7752:b2dbab2b34bc
fix(refactor): multiple fixups using ruff linter; more testing.
Converting to using the ruff linter and its rulesets. Fixed a number
of issues.
admin.py:
sort imports
use immutable tuples as default value markers for parameters where a
None value is valid.
reduced some loops to list comprehensions for performance
used ternary to simplify some if statements
named some variables to make them less magic
(e.g. _default_savepoint_setting = 1000)
fixed some tests for argument counts < 2 becomes != 2 so 3 is an
error.
moved exception handlers outside of loops for performance where
exception handler will abort loop anyway.
renamed variables called 'id' or 'dir' as they shadow builtin
commands.
fix translations of form _("string %s" % value) -> _("string %s") %
value so translation will be looked up with the key before
substitution.
end dicts, tuples with a trailing comma to reduce missing comma
errors if modified
simplified sorted(list(self.setting.keys())) to
sorted(self.setting.keys()) as sorted consumes whole list.
in if conditions put compared variable on left and threshold condition
on right. (no yoda conditions)
multiple noqa: suppression
removed unneeded noqa as lint rulesets are a bit different
do_get - refactor output printing logic: Use fast return if not
special formatting is requested; use isinstance with a tuple
rather than two isinstance calls; cleaned up flow and removed
comments on algorithm as it can be easily read from the code.
do_filter, do_find - refactor output printing logic. Reduce
duplicate code.
do_find - renamed variable 'value' that was set inside a loop. The
loop index variable was also named 'value'.
do_pragma - added hint to use list subcommand if setting was not
found. Replaced condition 'type(x) is bool' with 'isinstance(x,
bool)' for various types.
test_admin.py
added testing for do_list
better test coverage for do_get includes: -S and -d for multilinks,
error case for -d with non-link.
better testing for do_find including all output modes
better testing for do_filter including all output modes
fixed expected output for do_pragma that now includes hint to use
pragma list if setting not found.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Fri, 01 Mar 2024 14:53:18 -0500 |
| parents | 1a912887d704 |
| children | b4dfc68b7067 |
line wrap: on
line source
.. meta:: :description: Definitions of terms used in the Roundup Issue Tracker documentation. Referenced by other documents. ================ Roundup Glossary ================ .. glossary:: :sorted: class a definition of the properties and behavior of a set of items classname the name of a class. It must start with a letter, end with a letter or "_", and only have alphanumerics and "_" in the middle. db database used to store the data in the tracker. Roundup supports 4 databases: dbm (Berkeley DB/BDB), SQLite, PostgreSQL, MySQL/MariaDB. definitional class a class that exists to define a discrete set of values. For example status or priority. designator a combined :term:`classname` + :term:`itemid` reference to any item in the hyperdb. E.g. ``issue26``. Note that form values can include something that looks like a designator composed of a classname, a dash '-', and a number. E.g. ``file-1``. These are used to create new instances of a class via the web interface. hyperdb a software layer between the user and the underlying :term:`db`. It is responsible for mutating the underlying db when the schema changes. It also executes the detectors when items in the db change. item a collection of data that forms one entry in the hyperdb. itemid an integer reference to a particular item of one class. Internally it is stored as a string and not an integer number. This results in a string not numeric sort by id in some circumstances. property one element of data that makes up an item. In Roundup, the set of item properties may be changed as needed - even after the tracker has been initialized and used in production. schema the definition of all the classes and properties that make up a tracker. Contained in the file ``schema.py``. The permissions for the schema items are usually defined in the same file. tracker the schema and hyperdb that forms one issue tracker tracker home the physical location on disk of a tracker. It has the ``config.ini``, ``schema.py`` files for the tracker. ----------------- Back to `Table of Contents`_ .. _`Table of Contents`: ../docs.html
