<p dir="auto"><strong>Migrated issue, originally created by Anonymous</strong></p>
<p dir="auto">(original reporter: ged) Here is a patch which significantly speed up processing of PGArrays and also "fixes" the support for multi-dimensional PGArrays.</p>
<p dir="auto">In short, this patch introduces support for types like PGArray(PGArray(Integer)). However, multidimensional support <em>might</em> (I didn't actually test that case) have already worked without being explicitly declared (ie using a PGArray(Integer) as a multi-dimensional array) because Postgres does not enforce the number of dimension declared. IMO, this shouldn't be relied upon because it is probably a temporary situation.</p>
<p dir="auto">I didn't commit it directly because I fear the current way of doing things might have been intentional, given the current recursive code.</p>
<p dir="auto">Also, the attached patch tries to add some test for multi-dimensional arrays to the test suite but was <em>not</em> tested within the test suite because I couldn't run it (it seemed to be broken as of yesterday).</p>
<p dir="auto">Of course, I did test basic roundtrip, as in the attached testcase.</p>
<hr>
<p dir="auto">Attachments: <a href="../wiki/imported_issue_attachments/1591/stress_array.py">stress_array.py</a> | <a href="../wiki/imported_issue_attachments/1591/PGArray_multi_and_speed.diff">PGArray_multi_and_speed.diff</a></p>
<p dir="auto"><strong>Migrated issue, originally created by Anonymous</strong></p>
<p dir="auto">(original reporter: anthonyt) Like the title says, this is a test case for a bug that affects setting the contents of an InstrumentedList property.</p>
<p dir="auto">Essentially it boils down to: If there is an object X in a Many-To-Many relationship with a join table, and you remove it, then add it again, then flush, SQLAlchemy tries to insert a duplicate row into the join table.</p>
<p dir="auto">e.g. given the following...<br>
tables: users, groups, users_groups<br>
classes: User, Group<br>
and instances: u, g</p>
<p dir="auto">The following operations will succeed:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="    u.groups = [g](g)
    session.commit()
    u.groups.remove(g)
    session.commit()
    u.groups.append(g)
    session.commit()"><pre class="notranslate"><code class="notranslate">    u.groups = [g](g)
    session.commit()
    u.groups.remove(g)
    session.commit()
    u.groups.append(g)
    session.commit()
</code></pre></div>
<p dir="auto">But the following operations (missing the intermediate flush/commit) will fail:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="    u.groups = [g](g)
    session.commit()
    u.groups.remove(g)
    u.groups.append(g)
    session.commit()"><pre class="notranslate"><code class="notranslate">    u.groups = [g](g)
    session.commit()
    u.groups.remove(g)
    u.groups.append(g)
    session.commit()
</code></pre></div>
<p dir="auto">Runnable test case at <a href="https://gist.github.com/4449077">https://gist.github.com/4449077</a> though you'll have to edit the config dictionary to add your own user and database name.</p>