Equivalent to where clause in indexeddb

Question

Suppose we got a database for todolist and want to query all the important elements and have not yet completed. In SQL, I will use something like

SELECT * FROM todolist WHERE important = true AND state <> 'done' 

How can we execute this type of query in the indexeddb nosql database? With indexes? Another way? Not possible?

As I know, to filter the result by important = true :

 objectstore.index('important').openCursor(IDBKeyRange.only('true')) 

But I don’t know how to filter on state <> 'done' , since we only got IDBKeyRange.only(z) .

And I do not know how to filter both sentences.

NB: In MongoDB we do:

 db.userdetails.find({"date_of_join" : "16/10/2010","education":"MCA"}) 

Answer 1

To do this, you will need indexes, and you can get the data using the cursor, where you can provide one filter.

On my blog ( http://www.kristofdegrave.be/2012/01/indexed-db-reading-multiple-records.html?m=1 ) you can find more information about this.

Answer 2

In onupgradeneeded, create an index by the criteria that the array uses:

 todolistStore.createIndex('importantIncomplete', ['important','state'],{unique:false}); 

For your request, do:

 var lowerBound = ['true','started']; var upperBound = ['true','almostdone']; var range = IDBKeyRange.bound(lowerBound,upperBound); var request = todolistStore.index('importantIncomplete').openCursor(range); 

Answer 3

There are two ways to query multiple indexes in IndexedDB. Josh described the fastest way to query multiple fields using a composite index. However, it has a storage cost and slows down recording. In addition, the query must be known a priori, and therefore the index is created as necessary. The second method is manual key combining using the sorted merge algorithm or others. This method requires indexes (not compound) in the fields of interest and processes the entire combined query. See here http://dev.yathit.com/ydn-db/nosql-query.html for merge sort, nested loop and zigzag merge implementation in ydn-db library. I am involved in adding additional join algorithms.

By the way, we usually do not index a Boolean value. If your query field is a Boolean data type, just do a table scan. Do not use index.