4

We have been trying out JayData as the layer of abstraction to multiple data providers in an HTML5 web app that targets multiple platforms and devices.

We also have been using the Linq2IndexedDB library with some amount of success and using that library we were able to create indices for the tables. But so far we could not figure out how to do this using JayData IndexedDB provider or if this is even supported.

Could someone show how can JayData be used to create an index for an indexedDb table using JayData?

Hari Pachuveetil
  • 10,294
  • 3
  • 45
  • 68
  • I've check our own webpage about our own indexdb provider and the webpage is old and contains outdated informations. Sorry about it, we will update it soon, in the meantime please check our blogposts (jaydata.org/blog and jaystack.com/blog) for the latest news. – Gabor Dolla Nov 13 '12 at 21:42

3 Answers3

2

I can confirm that the support for indices is on the way - expect the release in this year. Not only for IndexedDB but for WebSQL/sqLite and mongoDB too. Also with the help of indices will come the support for navigation proprties for key based stores like indexeddb and mongodb in Q1 2013.

With regard transactions: everything considered one (logical) transaction that happens when a set of changes are saved with saveChanges. If the provider supports rollbacks than en error in saving any of the items will revert any previous changes in the same batch. As an example see this: webSQL transactions with JayData

@Kyaw Tun Please point me to the documentaion that states indexedDB is not important for JayData, we have to ammend it, thanks. I check your library

Community
  • 1
  • 1
Peter Aron Zentai
  • 11,482
  • 5
  • 41
  • 71
  • 1
    Sorry if I did offend. I do not like FUD on the emerging browser standard IndexedDB. The following statement on http://stackoverflow.com/questions/tagged/indexeddb are not true : `Vastly inferior to WebSQL, IndexedDb is yet to see wide adoption by vendors.` `these are not autodetected. This is an internal and intentional limitation of IndexedDb itself.` `it does not support filtering, projections or paging, so the full entityset must be retrieved each time.` paging and filtering are supported. – Kyaw Tun Nov 14 '12 at 10:47
  • One reason for starting IndexedDB is poor performance of WebSQL. You should change the documentation intonation to IndexedDB with respect. There are many web developer who do not have time to read IndexedDB API. Jumping to conclusion like your documentation is not helpful. – Kyaw Tun Nov 14 '12 at 10:51
  • IndexedDB API is very verbose, but it is for transaction and efficiency. There is NO other way. That does not mean the API is bad. All queries are possible in IndexedDB with proper indexing. – Kyaw Tun Nov 14 '12 at 10:53
  • BTW, in memory operation in browser is the the worse idea, I ever heard. If something is unreliable, don't do it. – Kyaw Tun Nov 14 '12 at 10:59
  • No offense taken, I really wanted to know where do our site state this. Now that you pointed me to the page I can change upon our intentions which is to bring as many features to indexeddb than we can. Now that chrome and IE10 has support for it - it now makes sense. – Peter Aron Zentai Nov 14 '12 at 11:01
  • Using the memory is not that bad an idea - if and when data size makes it feasible. I am not saying always, I am just saying that in 80% times in the client scenarios we are dealing with has data less then 200 rows. Consider a query with 5 fields to filter, and the overhead IndexedDB will impose if you apply it the way you suggest: Create 5 indices and 5 cursors and then the logic that crosswinds these cursors. The likelyness of a double/triple read here is O = log(N) with respect to the number of fields in the predicate and that is a massive overhead. – Peter Aron Zentai Nov 14 '12 at 11:12
  • I good implementation splits the workload, get that 200 from the many thouthsand rows with reducing the index usage to 1 or 2 fields, this 1 or 2 crosswindings tops. And then applies other filtering inmemory. So no, I can not agree with you that "in memory operation in browser is the worse idea" - imho seeing things black and white is a Sith approach. – Peter Aron Zentai Nov 14 '12 at 11:13
  • Sorry for wrong link, it should be http://jaydata.org/providers/indexeddb-provider – Kyaw Tun Nov 14 '12 at 11:17
  • Guys, stay on topic. But I want to say, when using indexeddb you don't have an other solution to do a part of the querying in memory. If not, you can't use multiple filters. Also the filtering with indexeddb is limited. Sorting is even worse. If you would use an index to sort, all values that don't have a property with the name described in the keyPath in the index would be ignored. To conclude: you need both to get the best performance – Kristof Degrave Nov 14 '12 at 11:20
  • Sorting, filter and joining is the job of a database. That is why we are using database. Otherwise we just use File API or key-value store. – Kyaw Tun Nov 14 '12 at 11:24
  • In Javascript, you have no control over memory. You don't know you have enough memory or even you don't know how much memory your data is using. Basically loading a lot of memory in browser is source of slow and unpredictable browser crush. – Kyaw Tun Nov 14 '12 at 11:27
  • But the indexeddb API doesn't support all that how will you do multiple filtering with sorting on top of it? – Kristof Degrave Nov 14 '12 at 11:29
  • `you can't use multiple filters.` you can use multiple filters or even multiple sorting. Multiple filters is obvious, just use two index key scanning. Multiple sorting had to do with array key like ['first', 'last']. this will sort first name after last name. – Kyaw Tun Nov 14 '12 at 11:30
  • But as a developer I want this... So the only way to at chive this is by doing it in memory – Kristof Degrave Nov 14 '12 at 11:31
  • `how will you do multiple filtering with sorting on top of it?` Start with sorting and then filter it. Multiple sorting and filtering supported in IndexedDB. And it is faster than WebSQL. – Kyaw Tun Nov 14 '12 at 11:39
  • Yes, it does need five index and five cursor operation. But they don't use memory and very reliable and predictable. For `with has data less then 200 rows.` case, you don't need database. `sort` and `slice` array method is just fine. – Kyaw Tun Nov 14 '12 at 11:49
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/19524/discussion-between-kristof-degrave-and-kyaw-tun) – Kristof Degrave Nov 14 '12 at 11:58
1

From their documentation, Jaydata don't think Indexeddb is worthy of efficient database. Apparently they ignore the most two important feature of indexeddb: indexing and transaction. However use properly Indexeddb is faster then websql.

Try my library https://bitbucket.org/ytkyaw/ydn-db/overview which love indexeddb so much and so many tricks to use it property.

Kyaw Tun
  • 12,447
  • 10
  • 56
  • 83
  • Thanks for the reply, but I was not looking for a library to handle indexedDb alone. – Hari Pachuveetil Nov 14 '12 at 01:34
  • I did not check out the lib itself, I was talking from the answer you posted here. I shall be evaluating your lib to see if it fits our needs. Thanks for the suggestion... – Hari Pachuveetil Nov 14 '12 at 16:01
  • I tried your library and I am sorry to say the documentation is really poor ! After spending the whole day trying to figure out things myself, I am giving up... – Hari Pachuveetil Nov 15 '12 at 21:24
  • It is young project. documentation and implementations are not matching. Check out unit test file or source codes. If whole day cannot figure out, I dont think worth using such library. A library must easy enough to use without reading manual. – Kyaw Tun Nov 15 '12 at 22:55
  • I agree. Part of it is because Closure is new to me, though I must say it is similar to jQuery (at least with the deferred and all). Anyways, I hope this would evolve into a very good library and I could come back to it one day. :) – Hari Pachuveetil Nov 15 '12 at 22:58
  • On the otherhand it is closure library. If there missing some expected methods, probably there is no efficient way to do it. There is no fake implementation. People freak out closure library dont have onready methods, a very handy and commonly use one. However people dont realize is it is a fake implementation, should not use at all. – Kyaw Tun Nov 15 '12 at 23:14
1

I'm the one developing the linq2indexeddb lib. If you have some issues around my lib, you can always tell me. I will take a look at it. Also if you want to support more browsers (the ones using WebSQL) you can add the indexeddb shim to your project. This is a shim for using the indexeddb API on top of the WebSQL API. I work closelly together with the developer of the shim so my lib also supports this.

Kristof Degrave
  • 4,142
  • 22
  • 32
  • We do know that the shim is there, but maybe we are not using it in the recommended way. I shall take another look at trying to abstract the provider specific code into one maintainable layer using linq2indexeddb. Thanks @KristofDegrave – Hari Pachuveetil Nov 14 '12 at 16:03
  • I am afraid I cannot get the shim to work - even your sample at http://users.telenet.be/kristofdegrave/ seems to be broken with Safari – Hari Pachuveetil Nov 14 '12 at 17:57
  • It looks as though, you have some integration issues with the latest version of the shim. Maybe I should only use the version of shim that you are shipping... Let me try that! – Hari Pachuveetil Nov 14 '12 at 21:27
  • Have sent you a couple of tweets – Hari Pachuveetil Nov 14 '12 at 22:03
  • I have seen them go by :). You can always create an issue on codeplex with the problems you are suffering. I'll do my best to resolve them asap. – Kristof Degrave Nov 15 '12 at 06:11
  • Try indexeddb polyfill from Facebook in github. It pass std browser test suite except Date – Kyaw Tun Nov 16 '12 at 15:30