Re: Replacing WebSQL with a Relational Data Model.

On that point it should be possible to build an efficient text search on top
of IndexedDB. You need a "word" index that links to multiple documents.
Matching documents are found by taking the intersection of the sets of
documents found for each word in the query (for an unstructured query). As
such you would put the documents in localStorage, and build a word index in
IndexedDB, there each record contained a list of document references.


Cheers,
Keean.


On 27 October 2010 09:43, Nathan Kitchen <w3c@nathankitchen.com> wrote:

> Sorry Keean, the main point of my post was to introduce the [featurecreep
> /], not critique your suggestions. I don't honestly care about the
> implementation of persistent browser storage, but I do care that it's
> fully-featured. nathan@webr3.org noted that we just need something to
> persist data from javascript. Although I agree with this, I think we
> additionally need native full-text search *as well as* CRUD. The Gears
> implementation of FTS (or rather, SQLite) exposed useful functionality but
> that needs
> *
> *
> In hindsight it was a little off-topic, but I saw it fly past and thought
> that while we were discussing offline storage features it'd be a good point
> to raise FTS.
>
> I'm also not sure about persisted JSON structures vs relational objects,
> but happy to see how the current spec pans out. It certainly involves
> thinking about an application's data architecture in a different way though.
>
> On Wed, Oct 27, 2010 at 9:10 AM, Keean Schupke <keean@fry-it.com> wrote:
>
>> Hi Nathan,
>>
>> On 27 October 2010 08:58, Nathan Kitchen <w3c@nathankitchen.com> wrote:
>>
>>> The most obvious problem was that it was tied so tightly to SQLite (which
>>> I think everyone would be amazed if MS started shipping with IE10). They'd
>>> want to use Access/SQL Compact, and suddenly we'd all have different SQL
>>> dialects to code our offline applications to.
>>
>>
>>
>>
>>
>>> Which is why I agree 100% with this statement:
>>>
>>>
>>> *The critical point here is that we need only one standardized
>>>> interface, not a perfectly optimized for data-model-x one, not a uses
>>>> query-language-foo one, just something that we can all use to persist data
>>>> from javascript, and wrap in other APIs, that way any optimizations made
>>>> will benefit everybody - regardless of their preferred interface, data model
>>>> & query style.*
>>>
>>>
>> And I totally agree with this statement, which is why I think it is
>> critical a _relationally_complete_ API is standardised (either in this, or a
>> later IndexedDB spec, or another spec entirely).
>>
>>
>> Cheers,
>> Keean.
>>
>>
>
>