This removes the optional dependence on SQL::Abstract::Classic or a version of SQL::Abstract prior to 2.000000, and only uses version 2.000000 or newer of SQL::Abstract.
For this to work the capability of a field override needs to be removed. There doesn't seem to be a reliable way to do that with the newer versions of SQL::Abstract, although I didn't try very hard. I also don't see the need for having a field override. The only field that has an override is the key_not_a_keyfield or key field. Why was that ever done? Did someone think that MySQL would make a field a database key field if it had the name "key"? Did someone think it would be confusing to have a field named "key" that was not a database key field? It was probably the latter, but in my opinion the field override was even more confusing.
The key field in the key table does not contain any permanent data, so upgrading courses does not require any special handling. The data from the old key_not_a_keyfield field can be safely dropped, and the new key field used in its place. You can leave the key_not_a_keyfield field in the database if you want to switch back and forth between other pull requests that use the key_not_a_keyfield field.
This removes the optional dependence on SQL::Abstract::Classic or a version of SQL::Abstract prior to 2.000000, and only uses version 2.000000 or newer of SQL::Abstract.
For this to work the capability of a field override needs to be removed. There doesn't seem to be a reliable way to do that with the newer versions of SQL::Abstract, although I didn't try very hard. I also don't see the need for having a field override. The only field that has an override is the
key_not_a_keyfieldorkeyfield. Why was that ever done? Did someone think that MySQL would make a field a database key field if it had the name "key"? Did someone think it would be confusing to have a field named "key" that was not a database key field? It was probably the latter, but in my opinion the field override was even more confusing.The
keyfield in thekeytable does not contain any permanent data, so upgrading courses does not require any special handling. The data from the oldkey_not_a_keyfieldfield can be safely dropped, and the newkeyfield used in its place. You can leave thekey_not_a_keyfieldfield in the database if you want to switch back and forth between other pull requests that use thekey_not_a_keyfieldfield.