Fix xmldb postgres generator to preserve unique keys during alter table
Bug #784341 reported by
Richard Mansfield
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mahara |
Won't Fix
|
Low
|
Unassigned | ||
Bug Description
See bug #784322.
| tags: | added: postgres |
| Changed in mahara: | |
| importance: | Wishlist → Medium |
| Changed in mahara: | |
| importance: | Medium → Low |
Revision history for this message
| Robert Lyon (robertl-9) wrote | #1 |
| Changed in mahara: | |
| milestone: | none → 1.9.0 |
| Changed in mahara: | |
| milestone: | 1.9.0 → 1.10.0 |
| Changed in mahara: | |
| milestone: | 1.10.0 → 1.11.0 |
| Changed in mahara: | |
| milestone: | 15.04.0 → 15.04.1 |
| Changed in mahara: | |
| milestone: | 15.04.1 → 15.10.0 |
| Changed in mahara: | |
| milestone: | 15.10.0 → 16.04.0 |
| Changed in mahara: | |
| milestone: | 16.04.0 → 16.10.0 |
| Changed in mahara: | |
| milestone: | 16.10.0 → 16.10.1 |
| Changed in mahara: | |
| milestone: | 16.10.1 → 17.04.0 |
| Changed in mahara: | |
| milestone: | 17.04.0 → 17.10.0 |
| Changed in mahara: | |
| milestone: | 17.10.0 → none |
| status: | Confirmed → Won't Fix |
To post a comment you must log in.
From what I understand the getAlterFieldSQL() function in postgres7.class.php will create a new temp column in some instances (for instance change of type / precision / decimal).
It will copy the data from the old unaltered field we are changing to the temp one, drop the old field and then rename the temp field to the new altered field.
I suspect that it is this process that is losing the unique keys. So there needs to be a check during the 'Take a look to field metadata' to see if there is any unique key and if so keep a track of it so we can add it back if needed.