Buzzinoffbond / phpliteadmin

Automatically exported from code.google.com/p/phpliteadmin
0 stars 0 forks source link

ALTER TABLE: Adding columns to a table with compound primary key fails (SQLite v2 only) #202

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a table like this:
CREATE TABLE 'books' ('author' TEXT NOT NULL, 'title' TEXT NOT NULL, PRIMARY 
KEY ('author', 'title'))
2. Try to add columns:
ALTER TABLE "books" ADD 'year' INTEGER

What is the expected output? What do you see instead?
Expected: column added successfully
Actual output: ERROR: ERROR: Altering of Table books failed - Table books does 
not exist.

PLA Version: 1.9.4
SQLite version: 2.8.17
SQLite extension [?]: SQLiteDatabase
PHP version: 5.3.3-7+squeeze15

Generally, ALTER TABLE problems are issue #12. This is a concrete example of 
what still does not work.

Original issue reported on code.google.com by crazy4ch...@gmail.com on 21 Mar 2013 at 11:14

Attachments:

GoogleCodeExporter commented 9 years ago
Moreover, we should get rid of the 2nd "ERROR".

Original comment by crazy4ch...@gmail.com on 21 Mar 2013 at 11:16

GoogleCodeExporter commented 9 years ago
The same problem is likely to happen with any other table-constraint like 
CONSTRAINT, CHECK, FOREIGN KEY, PRIMARY KEY, UNIQUE.
See https://www.sqlite.org/syntaxdiagrams.html#table-constraint

We probably need to add some lookahead in $preg_column_definiton that makes 
sure no column definition starts with one of these keywords.

Original comment by crazy4ch...@gmail.com on 21 Mar 2013 at 11:32

GoogleCodeExporter commented 9 years ago
The Debug output

Original comment by crazy4ch...@gmail.com on 22 Mar 2013 at 11:12

Attachments:

GoogleCodeExporter commented 9 years ago
Note: This issue only affects SQLite v2 DBs because v3 supports ALTER TABLE ADD 
and therefore, our own alterTable() function is not used in this case.

I am currently debugging this. A negative lookahead in $preg_pattern_add and 
catching table-constraints behind will do the job.

Original comment by crazy4ch...@gmail.com on 22 Mar 2013 at 12:44

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r379.

Original comment by crazy4ch...@gmail.com on 22 Mar 2013 at 3:57

GoogleCodeExporter commented 9 years ago
I just fixed this using a negative lookahead. Should work for all 
table-constraints.

I think we can include this in 1.9.4.1

Original comment by crazy4ch...@gmail.com on 22 Mar 2013 at 3:59