Project Versions

A custom list that manages index/position information for contained
elements.

author:

Jason Kirtland

orderinglist is a helper for mutable ordered relationships. It will
intercept list operations performed on a relationship()-managed
collection and
automatically synchronize changes in list position onto a target scalar
attribute.

Example: A slide table, where each row refers to zero or more entries
in a related bullet table. The bullets within a slide are
displayed in order based on the value of the position column in the
bullet table. As entries are reordered in memory, the value of the
position attribute should be updated to reflect the new sort order:

The standard relationship mapping will produce a list-like attribute on each
Slide containing all related Bullet objects,
but coping with changes in ordering is not handled automatically.
When appending a Bullet into Slide.bullets, the Bullet.position
attribute will remain unset until manually assigned. When the Bullet
is inserted into the middle of the list, the following Bullet objects
will also need to be renumbered.

The OrderingList object automates this task, managing the
position attribute on all Bullet objects in the collection. It is
constructed using the ordering_list() factory:

The OrderingList construct only works with changes to a
collection, and not the initial load from the database, and requires that the
list be sorted when loaded. Therefore, be sure to specify order_by on the
relationship() against the target ordering attribute, so that the
ordering is correct when first loaded.

Warning

OrderingList only provides limited functionality when a primary
key column or unique column is the target of the sort. Operations
that are unsupported or are problematic include:

two entries must trade values. This is not supported directly in the
case of a primary key or unique constraint because it means at least
one row would need to be temporarily removed first, or changed to
a third, neutral value while the switch occurs.

an entry must be deleted in order to make room for a new entry.
SQLAlchemy’s unit of work performs all INSERTs before DELETEs within a
single flush. In the case of a primary key, it will trade
an INSERT/DELETE of the same primary key for an UPDATE statement in order
to lessen the impact of this limitation, however this does not take place
for a UNIQUE column.
A future feature will allow the “DELETE before INSERT” behavior to be
possible, allevating this limitation, though this feature will require
explicit configuration at the mapper level for sets of columns that
are to be handled in this way.

ordering_list() takes the name of the related object’s ordering
attribute as an argument. By default, the zero-based integer index of the
object’s position in the ordering_list() is synchronized with the
ordering attribute: index 0 will get position 0, index 1 position 1, etc. To
start numbering at 1 or some other integer, provide count_from=1.

attr¶ – Name of the mapped attribute to use for storage and retrieval of
ordering information

count_from¶ – Set up an integer-based ordering, starting at count_from. For
example, ordering_list('pos',count_from=1) would create a 1-based
list in SQL, storing the value in the ‘pos’ column. Ignored if
ordering_func is supplied.

Optional. A function that maps the position in
the Python list to a value to store in the
ordering_attr. Values returned are usually (but need not be!)
integers.

An ordering_func is called with two positional parameters: the
index of the element in the list, and the list itself.

If omitted, Python list indexes are used for the attribute values.
Two basic pre-built numbering functions are provided in this module:
count_from_0 and count_from_1. For more exotic examples
like stepped numbering, alphabetical and Fibonacci numbering, see
the unit tests.

Default False. When appending an object with an existing (non-None)
ordering value, that value will be left untouched unless
reorder_on_append is true. This is an optimization to avoid a
variety of dangerous unexpected database writes.

SQLAlchemy will add instances to the list via append() when your
object loads. If for some reason the result set from the database
skips a step in the ordering (say, row ‘1’ is missing but you get
‘2’, ‘3’, and ‘4’), reorder_on_append=True would immediately
renumber the items to ‘1’, ‘2’, ‘3’. If you have multiple sessions
making changes, any of whom happen to load this collection even in
passing, all of the sessions would try to “clean up” the numbering
in their commits, possibly causing all but one to fail with a
concurrent modification error.

Recommend leaving this with the default of False, and just call
reorder() if you’re doing append() operations with
previously ordered instances or when doing some housekeeping after
manual sql operations.