Stored persistent ID and migration to 3.2

[Cantor, Scott]

On 11/20/15, 9:50 AM, "users on behalf of Simon Lundström" <users-bounces at shibboleth.net on behalf of simlu at su.se> wrote:



>Is that something you need to fix or for us deployers to configure?

You, but we can collect up the codes we need to retry on and just add them to future versions too.

>One question regarding the instructions in PID docs [1] though, it says
>"Dump the existing table, *reordering the data in the select statement*,
>and then load the data back into the recreated table." (emphasis mine).
>It can be something specific to another RDBMS but in a MySQL dump there
>isn't any SELECT-statement in a dump. IIRC neither is there one in one
>from Postgres? Maybe it can be done more generic?

Dump was a general term. How you do it is your choice, but if you can't create a primary key, then you have to figure out if you can apply a unique constraint some other way, or reorder the data.

>And to the real question; why would it need to be rearranged? Because
>the Stored ID DDL reorders them? Why does it reorder them? Seems like a
>lot of work for deployers for nothing worth?

Some databases do not allow non-consecutive primary key columns.

>I just added the PRIMARY KEY triplet and removed our other indexes
>(which probably were wrong anyway) and it worked.

That's not generically successful in my testing but I can suggest people try it.

-- Scott