android sqlite db 研究(1)

最近在研究android数据库，感觉这个东西好诡异，经常搞的一头雾水，总结一下最近的收获。

错误理解：android提供本地数据库provider机制，android本地数据库，图片、媒体库等数据是怎么来的呢？开始感觉是本地的app提供的，比如图库的图片的话就是那个图库的源码里有provider，但是查看源代码发现，没有对应的provider，程序中操作也是通过resolver来操作的，那么数据怎么来的

app路径：source\packages\apps

学艺不精，android本地数据库提供有专门的provider提供的。

源代码路径：source\packages\providers

这里看到了provider提供者，那么数据库也该在这个文件夹下面了,data/data下面可以看到.找到了.db文件网上找到一个可以打开这个数据库的工具SQLiteSpy.exe

看到了数据库文件

感觉能看到数据库文件了这样操作起来就很方便了,可以经常看看数据操作是否成功.可是慢慢的发现这个数据库怎么总是滞后

1. 插入一条数据  根据返回的uri得到id 

2. 查看数据库 的记录没看到对应的id

3. 再仔细看看文件修改时间 .db文件根本没有更新,是下面两个文件在随着操作更新.

针对wal看看

Beginning with version 3.7.0, SQLite supports a new transactioncontrol mechanism called "write-ahead log" or "WAL".When a database is in WAL mode, all connections to that database mustuse the WAL. A particular database will use either a rollback journalor a WAL, but not both at the same time.The WAL is always located in the same directory as the databasefile and has the same name as the database file but with the string"-wal" appended.

上面个是salite官网的一段英文,大概意思是讲wal是中新的用户数据回滚和容错处理的机制.经过网上查找资料得到的知识,讲的是sql数据库的优化策略.因为用户发现插入操作很慢,不是因为数据库操作慢,因为事物的原因.这样把操作放在日志里,到一定的触发时机进行触发,那是什么触发时机呢,先把手机的时间调节了一下,看看是不是按照时间来触发的,发现不是那么回事儿,这样的触发时机太不可控了,也不合理.然后对数据库进行了一次暴力操作,连续插入删除进行了很多次操作.然后再查看数据库的db文件发现数据库这个时候更新了,可还是不是最新的数据.也就是说,在log里还有一部分没有提交.使用的是一种分页机制.当数据日志写到了某个point 这个时候提交给db.

可这样操作就让人很费解了.我们的更新操作:增加/删除/修改操作可以理解,只需要在log日志中进行登记,到一个checkpoint进行一次提交就可以了.可是我们的query操作呢?

我们想要查询数据库的时候是怎么操作的呢?数据库中的文件不是最新的啊.

遗留问题：

查询操作是如何处理的？难道是先查询db，然后再在wal中进行覆盖，最后返回结果？

今天冒出来一个想法，那个查看工具可不可以读取wal中的信息呢？把整个数据库文件拷贝出来打开后发现，这样数据就能及时的看到了，饶了一大圈