Make SQLiteDatabase ref counted
Created attachment 63732 [details] Patch
Attachment 63732 [details] did not build on qt: Build output: http://queues.webkit.org/results/3628515
Attachment 63732 [details] did not build on mac: Build output: http://queues.webkit.org/results/3612635
So far looks like simple breakage. Will fix before landing + watch bots when I land.
I'm not sure we should make SQLiteDatabase ref-counted. It's just a simple wrapper around sqlite3* + C++ interface to some sqlite functions, and I think it should stay that way. Also, don't you want to pass around some state associated with this DB, too? In that case, it seems to me that it might be better to have a ref-counted "wrapper" with additional state (like AbstractDatabase), and pass around instances of that class. I think you also missed a couple of references to this class: WebCore/loader/icon/IconDatabase and WebCore/loader/appcache/ApplicationCacheLoader
Attachment 63732 [details] did not build on win: Build output: http://queues.webkit.org/results/3656253
I'm with dumi on this one. Making that class refcounted adds complexity that would be nice to avoid. For the indexedDB use case, can you create a new refcounted class to hold the instance to be shared?
Attachment 63732 [details] did not build on gtk: Build output: http://queues.webkit.org/results/3566984
The use case here is that IDBFactory needs to open the database and do some initial reads before creating an IDBDatabase class which will then take ownership. So I can just heap allocate it and then pass it in to the IDBDatabase class and it'll work. But we use ref counted objects in most other cases like this. That's why ref counting is so heavily optimized: it's often used for cases where there aren't many links. But I don't care that much, so I'll close this for now. Personally I think the object probably should have been ref counted to begin wtih.
On the other hand, the direction WebKit is headed is to never do a new outside of a create() factory. This is going to force me to do that (and I believe it's been done in other parts of the code)? Thus this really should be at a very have a private constructor and a factory that returns a PassOwnPtr. Of course the other SQL wrappers should probably have the same thing. But that'll make stack allocating stuff much less clean (syntax wise). So maybe it's worth punting on this for now....but the trend is for code like this to go away.