- SQLite語句
- 增加表字段 ALTER TABLE 表名 ADD COLNUM 字段名 字段類型
- 刪除表字段 ALTER TABLE 表名 DROP COLNUM 字段名
- 修改表字段 ALTER TABLE 表名 RENAME COLNUM 舊字段名 TO 新字段名
SQLite的線程安全
http://stackoverflow.com/questions/6675240/is-sqlite-database-instance-thread-safe
No, it is not thread-safe by default. You shoud use locking-related SQLiteHelper methods to provide thread safety.
http://stackoverflow.com/questions/11058098/interprocess-sqlite-thread-safety-on-ios
I've never used SQLite, but I've spent a decent amount of time reading its docs because I plan on using it in the future (and the docs are interesting). I'd say that thread safety is independent of whether multiple processes can access the same database file at once. SQLite, regardless of what threading mode it is in, will lock the database file, so that multiple processes can read from the database at once but only one can write.
Thread safety only affects how your process can use SQLite. Without any thread safety, you can only call SQLite functions from one thread. But it should still, say, take an EXCLUSIVE lock before writing, so that other processes can't corrupt the database file. Thread safety just protects data in your process's memory from getting corrupted if you use multiple threads. So I don't think you ever need to worry about what another process (in this case iOS) is doing with an SQLite database.
Edit: To clarify, any time you write to the database, including a plain INSERT
/UPDATE
/DELETE
, it will automatically take an EXCLUSIVE lock, write to the database, then release the lock. (And it actually takes a SHARED lock, then a RESERVED lock, then a PENDING lock, then an EXCLUSIVE lock before writing.) By default, if the database is already locked (say from another process), then SQLite will return SQLITE_BUSY without waiting. You can call sqlite3_busy_timeout()
to tell it to wait longer.CoreData的線程安全
看到知乎上有人說core data是支持多線程的秋秤，但需要thread confinement的方式實(shí)現(xiàn),使用了多線程之后可以最大化的防止阻塞主線程。待實(shí)驗(yàn)
