My app is in production and I want to manage user data when user updates the app without loss of their data, how can I achieve this with sqflite. Explicitly I want to add a column and delete another.
You can probably add a column using raw sql, but sqlite (and thus sqflite) doesn't support dropping a column. For that you would need to do the following:
increase the database version number
in onUpgrade copy the old database columns to a temporary table
delete the original table
create a new table using the original table name but with the right schema
copy the data from the temp table
delete the temp table
Sorry, this isn't a full answer, but it is the direction I would go if I were in your situation.
I have the same problem and found this article which seems to be a good solution.
Related
I am trying to delete column last_name from Persons using FMDB,
let query = "ALTER TABLE Persons DROP COLUMN last_name;"
try FMDBHelper.database.executeUpdate(query, values: nil)
But comes with error
DB Error: 1 "near "DROP": syntax error".
sqlite does not support DROP COLUMN in ALTER TABLE.
You can only rename tables and add columns.
If you need to remove columns, create a new table, copy the data there, drop the old table and rename the table to its intented name.
Reference: http://www.sqlite.org/lang_altertable.html
Please note that I flagged that your question could be duplicated, I will provide an answer to make it more clear.
I think that you are missing a point, which is: The FMDB is (as mentioned in their repo description):
This is an Objective-C wrapper around SQLite
Keep in mind that since FMDB is built on top of SQLite, it is not a limitation from the library itself; it is related to how SQLite ALTER TABLE works.
The SQLite ALTER TABLE statement is limited to rename a table and add a new column to the desired table:
SQLite supports a limited subset of ALTER TABLE. The ALTER TABLE
command in SQLite allows the user to rename a table or to add a new
column to an existing table.
http://www.sqlite.org/lang_altertable.html
For achieving what are you looking for:
You could check the answers of Delete column from SQLite table.
Is there a way to know when a user updates a table column? For example, at what time a user changes their last name?
Im not interested when last a table was updated; only the column. Is it possible using Rails 5 and PostgreSQL?
If you are including timestamps in your models (.created_at and .updated_at) then .updated_at will tell you the last time that the record (i.e. the database row) was updated.
But that will not tell you which attribute of the record was changed (i.e. which database column). Nor will it tell you which user changed it, or if it was changed automatically by something in your system, etc.
You would need the schema to do that. You can a new table called as user_logs and implement a trigger which stores old_record and new_record. This will help you to get the desired log for change.
In Spotfire, I have inserted columns From an Excel File in an existing Data Table on Spotfire (See example shows at the End) but I have made a mistake in the join property. Could I change it without re creating the complete Data Table or using calculated columns/Filters?
You can only edit it by deleting the inserted columns and adding them again.
Running Rails 4 with Postgres 9.4 in development and production. I've got a large table that has grown by migrations over time. Because of the many different columns on the table, I want to reorder things so that the columns are grouped more logically. In other words, some column elements naturally group together based on what information they capture.
I found a discussion on using after: in a migration to reorder columns (using ALTER TABLE in SQL), at this stack overflow discussion. I then went ahead and set up a migration to do that. After running the migration I notice that my schema.rb file hasn't changed. Looking at the columns in the database (postgres on development), nothing has changed there either.
Further research led me to the Postgres wiki, which states there is currently no support for altering column position in Postgres.
This isn't mission critical, but it would make life easier. My question is:
If I simply move lines in the schema.rb file up or down in order to position them as desired, will that cause any problems? Since I expect to provision any new database with rake db:schema:load, it wouldn't seem like that should break anything. Further, since the previous migrations aren't materially changed (just the order of columns they output to schema.rb) everything should be internally consistent, no?
If that's a bad idea, can I simply go back into the earlier migrations, add the syntax for after: :some_column to each column element so they correctly set up the schema.rb file?
My assumption is that when I rebuild my production database from scratch with seed data, it will use the schema structure to correctly create the table in the desired order. Right now it's not a real, deployed database with end users, so it doesn't seem like an issue. Using option #1 above seems like the easiest solution, as long as it doesn't break anything.
Many people new to postgresql often ask if it has support for altering
column positions within a table. Currently it does not; if you want to
change column positions, you must either recreate the table, or add
new columns and move data. The idea of allowing re-ordering of column
position is not one the postgresql developers are against, it is more
a case where no one has stepped forward to do the work.
ref
If I simply move lines in the schema.rb file up or down in order to
position them as desired, will that cause any problems?
no. It does nothing with column order in PG.
If that's a bad idea, can I simply go back into the earlier migrations, add the syntax for after: :some_column to each column element so they correctly set up the schema.rb file?
after: :some_column option does nothing with column order if you use PG
The order of your columns does not matter to Ruby or Rails.
As to whether it matters to any code you wrote, only you and your tests can answer that. If you're only using ActiveRecord and not doing any straight SQL that references column number, you should be fine.
As a workaround, you can use annotate to document your models in the code and then reorder the created comment there.
Of course, that will probably be overwritten by annotate once you run it again. And it will only make your life easier if you look at the table structure, but it won't help if you manually run SQL queries with SELECT * in your db.
In Rails, when a record is to be deleted, I want to maintain a separate table for such deleted records (that in structure would be analogous to the former).
One way to achieve this would be to obviously copy the structure, validations and associations from the first model and paste it into the deleted items model. This would, however, result in a lot of code redundancy and is not a scalable solution.
Is there a way to achieve this in Rails without much (or any) code redundancy
or a solution that might be more scalable than the one mentioned
above?
I am using Ruby 1.9.3-p125 and Rails 3.2.
UPDATE
I did consider using an additional is_deleted column in the table, however, I decided against it because I didn't want this table to get too big and messy with deleted posts. I don't intend to really access these deleted posts - these are merely stored for record-keeping or archival purposes. Adding this column would also make accessing this table slower and more importantly, I am afraid that I may miss the check is_deleted == false in some SQL condition somewhere - even if I include this check in the default_scope of the model.
It is good idea to move them to separate table so that your primary table have less number of records and performance is not decreased by time.
Use Rails ActiveRecord Callback for deletion i.e.
before_destroy :move_to_trash
.
.
def move_to_trash
Trash.create!(self)
end
In this way, when a record is deleted, its copy will be created in Trash table.
Well, basically you want to keep the records and not throw them away. So you may want to just mark them "deleted" and tweak the logic in your code to not consider those records while retrieving them.
Add a 'deleted' column in your original table. Set the default scope of the model to exclude deleted records.