[Webkit-unassigned] [Bug 62780] Migrate SQLite backing store to LevelDB backing store for Indexeddb.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=62780





--- Comment #9 from Hans Wennborg <hans at chromium.org>  2011-06-21 07:52:49 PST ---
(In reply to comment #8)
> > > Source/WebCore/storage/IDBFactoryBackendImpl.cpp:95
> > > +    IDBBackingStoreMap::iterator it2 = m_backingStoreMap.find(uniqueIdentifier);
> > 
> > This is a regression of what I fixed in Bug 62382. It is important that m_backingStoreMap is keyed *per origin* (fileIdentifier) rather than per database (uniqueIdentifier).
> > 
> > The m_backingStoreMap's purpose is to cache open backing stores, so that we only keep a single connection to each backing store. If a LevelDB database is opened more than once simultaneously, it will cause corruption.
> 
> The backend keeps a pointer to a backing store so they are related even though they are separate C++ objects. This is an important fact in the migration code which is why I keep them together.

Yes, they are related, but it's not a 1-1 relationship, it's more like 1-n since there can be n databases for each backing store.

I see that it's important to keep backing stores with LevelDB vs SQLite apart, which we can do by making the store type part of the fileIdentifier.

It's essential that we keep track of which backing stores are open, and make sure we don't open the same one twice. That's what m_backingStoreMap, keyed with fileIdentifier, does.



> > > Source/WebCore/storage/IDBFactoryBackendImpl.cpp:159
> > > +                keyPath = true;
> > 
> > Maybe "bool hasKeyPath = !fromKeyPaths[i].isEmpty();" is simpler. Also, I'm not sure what this is used for, see comment below.
> > 
> > > Source/WebCore/storage/IDBFactoryBackendImpl.cpp:181
> > > +                ASSERT(keyPath);
> > 
> > If I understand correctly, this asserts that the object store has a key path. I don't see why that would hold? It's prefectly ok for an object store not to have a key path, and have indexes.
> 
> I guess am misunderstanding the spec then because it mentions indexes using a key ath. I can remove the assertion.

An index always has a key path. An object store may or may not have one. The assert seems to check for an object store key path.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.