Mercurial > p > roundup > code
view doc/glossary.txt @ 7668:5b41018617f2
fix: out of memory error when importing under postgresql
If you try importing more than 20k items under postgresql you can run
out of memory:
psycopg2.errors.OutOfMemory: out of shared memory
HINT: You might need to increase max_locks_per_transaction.
Tuning memory may help, it's unknown at this point.
This checkin forces a commit to the postgres database after 10,000
rows have been added. This clears out the savepoints for each row and
starts a new transaction.
back_postgresql.py:
Implement commit mechanism in checkpoint_data(). Add two class level
attributes for tracking the number of savepoints and the limit when
the commit should happen.
roundup_admin.py:
implement pragma and dynamically create the config item
RDBMS_SAVEPOINT_LIMIT used by checkpoint_data.
Also fixed formatting of descriptions when using pragma list in
verbose mode.
admin_guide.txt, upgrading.txt:
Document change and use of pragma savepoint_limit in roundup-admin
for changing the default of 10,000.
test/db_test_base.py:
add some more asserts. In existing testAdminImportExport, set the
savepoint limit to 5 to test setting method and so that the commit
code will be run by existing tests. This provides coverage, but
does not actually test that the commit is done every 5 savepoints
8-(. The verification of every 5 savepoints was done manually
using a pdb breakpoint just before the commit.
acknowledgements.txt:
Added 2.4.0 section mentioning Norbert as he has done a ton of
testing with much larger datasets than I can test with.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Thu, 19 Oct 2023 16:11:25 -0400 |
| 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
