I have a simple database schema containing 5 tables and a few foreign key relationships. Now I want to update the schema without losing the relationships.
SQLite does not support the operation I want to perform. I want to mark a column AUTOINCREMENT. So I searched and found that I need to recreate the tables.
In all the relationships, foreign key is the auto-generated row ID. This will change when I re-insert the data (right?). And the best case scenario would be having mismatched relationships. The worst case (I think) would be having foreign keys that correspond to nothing. How do I avoid this?
One way that I can think of doing this is through dumping all data into a special model designed for this very exercise. This special model will encapsulate all the relationships. Then I can start creating new tables in order of ascending dependence, from least to most. Table that has no foreign keys (but other tables use its ID) goes in first. And on inserting rows, I update the model instance.
Is there a better way of doing this? Thank you for reading.
Values in an autoincrementing column can be set to an explicit value:
INSERT INTO MyTable(MyAutoincID, Name) VALUES(42, 'hello')
Just copy the ID together with the other column values.
Furthermore, as long as you do not enable foreign key checking with PRAGMA foreign_keys or setForeignKeyConstraintsEnabled(), your DB is allowed to have inconsistent data temporarily.
Related
I have some kind of this table.
The question is what is the best way to create this kind of table?
Should I create for each item one table is it possible to create only one table??
Updated: See comments under #Emil.
You should have 1 tables as #Emil has suggested.
This should look like, soemthing like
_id, sort, grade, diameter, length, price1_dol, price1_euros, price2_dol, price2_euros, final,
Note: I have split up prices columns up - so you have price1_dol, price1_euros, price2_dol, price2_euros.
It is indeed possible to make this data into just one table. The columns sort and grade seem to uniquely identify one row so together they might make up a candidate key. If so you could use those as your primary key, or create a new integer column that you use as the primary key.
You should definitely not create one table per item. The database schema should never change with normal use. Only when you add, remove or change the type of data you have in your database should you consider changing the schema. Otherwise you should design and normalize your database in such a way that it's possible to grow the data only by inserting new rows, not new tables.
I have an app published in the play store.
The app uses a database which holds a table which has a column of type int.
I'm doing a new change where I need to change the column type to long.
How do I go about handling it in the DatabaseHandler I'v created.
I want to preserve the data stored in the older apps database, so what should ideally be the code in the onUpgrade() function???
You don't need to change the database column type. An INTEGER column will happily contain all the bits needed to represent a Java long.
In fact, there's no long column type in sqlite.
I think using SQLite, the best way is to create a temporary table, copy all your table content, drop the old table and recreate the table with the right type on your column, then you can just copy the content from the temporary table and drop it...
I know this don't fell like the best approach, but I don't think SQLite have some alter table function.
As far I know you can t do this . But You can drop your table if it exists and create it again . Maybe you can find out some useful information here SQLite Modify Column or here Modify a Column's Type in sqlite3
I am having a table with 'int' column. During software upgrade, I want to change it to 'long' data type. It seems SQLite does not provide an option (in alter statement) to change/modify column properties. Since I want to do an upgrade, the table might contain data which the user should not lose. So please suggest me a good method to change the column data type property without data loss.
One way suggested in the search links is to create a temporary table, copy the records from the existing table, delete the existing table, and rename the temporary table. I doubt that is efficient.
Your help appreciated!
Regards
Vivek Ragunathan
I used the follow statements to change the type of the column.
CREATE TABLE IF NOT EXISTS **TEMP_TABLE** (id integer primary key autoincrement, **col2change integer not null**, ...)
INSERT INTO TEMP_TABLE SELECT * FROM EXISTING_TABLE
DROP TABLE EXISTING_TABLE
ALTER TABLE TEMP_TABLE RENAME TO EXISTING_TABLE
I changed the int type column in the existing table to integer type. For a few hundred rows, it was reasonably fast.
SQLite3 columns do not have data types, only affinities -- there is no benefit in changing the column type from int to long.
If a wrapper program is truncating values before giving them to SQLite3, there is a way to fix this by editing the schema. It is a dangerous operation, so do it only after backing up your database. The schema is stored in the table sqlite_master; normally it is read-only, but you can modify it if you enable it with the writable_schema pragma. Be careful to only make changes that do not invalidate your data; you may change int to long int since they both have INTEGER affinity.
From SQLite documentation
It is not possible to rename a column, remove a column, or add or
remove constraints from a table.
Check this link
Please do remember that column data types are not rigid in SQLite. Check this link
Edit:
Following your comments on another answer, I guess the option you mentioned - working through the temp table - is the only one, which is not efficient off course.
you could add a new colum, copy the values form the old to the new column, delete the old column and then rename the new column to the old name
AFAIK there is no way in Android to change column data types once a table is created and used. The practiced way is to make a new table and copy the data which you read about
I have a very simple link table set up, I need to delete rows from all 3 tables
Table 1 - Assignment {assignment_id}
LinkTable - AssignmentTasks {assignment_id, task_id}
Table 2 - Tasks {task_id}
I can delete from Assignment and AssignmentTasks easily as I have the Id but I don't have the list of Tasks related to this assignment.
I've built a cursor which returns all the task_ids related to an assignment, but I can't remove them whilst the records in the link table refer to them. (I don't think I can as the foreign key constraint should stop me deleting rows referenced elsewhere)
Do I need to store a list of task_ids, delete the assignment_tasks records, delete the assignment record then iterate through the stored list of task_ids and delete each task ? or is there a better way of doing this ?
Or you can turn foreign key constraint checking off temporarily:
pragma foreign_keys = off;
But that shouldn't be necessary.
The other issue here is that this is currently written as a many-to-many relationship. This would imply that multiple assignments could refer to a one task. It probably wouldn't be OK to delete the task just because one of the assignments referencing it was deleted. Instead, you would need to check that the task is no longer referenced before deleting it.
Alternatively, if you really meant for each task to belong to only one assignment, you could set your schema up like this:
CREATE TABLE Assignment (assignment_id int PRIMARY KEY);
CREATE TABLE Task (
task_id int PRIMARY KEY,
assignment_id int FOREIGN KEY REFERENCES Assignment ON DELETE CASCADE
);
The ON DELETE CASCADE bit causes the Task entry to be deleted in the event that the assignment it refers to is deleted. This only works if foreign key constraints are enabled, of course. If the assignment is being deleted by a trigger or due to some other cascade, you may need to enable recursive triggers as well with pragma recursive_triggers = on.
Another possibility (if you want to retain the original schema) is to make the foreign key references in the AssignmentTask table do the cascading delete. That way those rows are deleted automatically as you delete the Tasks. Then you can delete the Assignment once all of those are taken care of.
Why not query the task_id based upon the assignment_id that you intent to delete.
You can leave the deletion of the related data to the database but that depends if you have defined cascade action onDelete when you created the relationships.
If you intend to use cascade onDelete as far as I know you need to enable that on sqlite. See this post for how to. Foreign key constraints in Android using SQLite? on Delete cascade
You can use a raw query. e.g.
delete from tasks where task_id in (select task_id from assignments where assignment_id=your_assignment_id_here)
I would also suggest using transaction for this for two reason a) so you can rollback in case the either of your queries fail. b) sqlite in general works better with transactions speedwise if you have multiple queries. So place all of your delete queires for a given action in a transaction.
Link below is for rawQuery:
http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html#rawQuery(java.lang.String, java.lang.String[])
The Android app that I am currently working on dynamically adds columns to an SQLite database. The problem I have is that I cannot figure out a way to remove these columns from the database.
If I add column A, B, C, D, and E to the database, is it possible to later remove column C?
I have done a lot of looking around and the closest thing I could find was a solution that requires building a backup table and moving all the columns (except the one to be deleted) into that backup table.
I can't figure out how I would do this, though. I add all the columns dynamically so their names are not defined as variables in my Java code. There doesn't seem to be a way to retrieve a column name by using Android's SQLiteDatabase.
SQLite has limited ALTER TABLE support that you can use to add a column to the end of a table or to change the name of a table.
If you want to make more complex changes in the structure of a table, you will have to recreate the table. You can save existing data to a temporary table, drop the old table, create the new table, then copy the data back in from the temporary table.
For example, suppose you have a table named "t1" with columns names "a", "b", and "c" and that you want to delete column "c" from this table. The following steps illustrate how this could be done:
BEGIN TRANSACTION;
CREATE TEMPORARY TABLE t1_backup(a,b);
INSERT INTO t1_backup SELECT a,b FROM t1;
DROP TABLE t1;
CREATE TABLE t1(a,b);
INSERT INTO t1 SELECT a,b FROM t1_backup;
DROP TABLE t1_backup;
COMMIT;
SQLite doesn't support a way to drop a column in its SQL syntax, so its unlikely to show up in a wrapper API. SQLite doesn't often support all features that traditional databases support.
The solutions you've identified make sense and are ways to do it. Ugly, but valid ways to do it.
You can also 'deprecate' the columns and not use them by convention in newer versions of your app. That way older versions of your app that depend on column C won't break.
Oh... just noticed this comment:
The app is (basically) an attendance tracking spreadsheet. You can add
a new "event" and then indicate the people that attended or didn't.
The columns are the "events".
Based on that comment you should just create another table for your events and link to it from your other table(s). You should never have to add columns to support new domain objects like that. Each logical domain object should be represented by its own table. E.g. user, location, event...
Was writing this initially. Will keep it if you're interested:
Instead of dynamically adding and removing columns you should consider using an EAV data model for that part of your database that needs to be dynamic.
EAV data models store values as name/value pairs and the db structure never needs to change.
Based on your comment below about adding a column for each event, I'd strongly suggest creating a second table in which each row will represent an event, and then tracking attendance by storing the user row id and the id of the event row in the attendance table. Continually piling columns onto the attendance table is a definite anti-pattern.
With regards to how to find out about the table schema, you can query the sqlite_master table as described in this other SO question - Is there an SQLite equivalent to MySQL's DESCRIBE [table]?
As per SQLite FAQ, there is only limited support to the ALTER TABLE SQL command. So, the only way you can do is that ou can save existing data to a temporary table, drop the old table, create the new table, then copy the data back in from the temporary table.
Also you can get the column name from the database using a query. Any query say "SELECT * FROM " gives you a cursor object. You can use the method
String getColumnName(int columnIndex);
or
String[] getColumnNames();
to retrieve the names of the columns.