Closed swapnil0545 closed 8 years ago
I see. I guess only dev version will cause problem. If you use non dev files, this issue should disappear.
I will resolve this on next release.
You are right the production version ydn.db-iswu-core-e-qry.js didn't gave me any errors but still I will like to work with dev environment. Also there is no prod environment if I select Cursor Iteration.
Thank you for the support.I will be waiting for the next version (webworker version :P)
For what it is worth, getting ydn-db to work inside a FF extension required using some of the Addon SDK's libraries. I used window for atob, timers for timeout and interval, and of course indexed-db. Not sure if its worth it to try to integrate this into the main tree. However, getting accepted to addons.mozilla.org is extremely difficult when using a fork, so it would be nice.
fixed with 0.9.0
I was trying to upgrate to 1.3.3 from 1.0.4 and this issue exists on 1.3.3 on both the prod as well as dev version. Happens when I add webstorage in the package. So on Safari I keep getting the error - ReferenceError: Can't find variable : window
Really! I remember I replace all window
reference. Please provide me a single html page, I will fix.
This happens only when I use it inside the worker process as it does not have access to window object. I will create a demo html and give it back to you. But you can see the window references(search window) https://storage.cloud.google.com/ydn-db-d1/1.3.3/ydn.db-isw-core-qry.js https://storage.cloud.google.com/ydn-db-d1/1.3.3/ydn.db-isw-core-qry-dev.js
While in worker script, if I use production version and pass in the options argument as
var options = {
mechanisms: ['websql'], // default ordering
size: 50 * 1024 * 1024 // 50 MB
};
new ydn.db.Storage('Information', schema, options);
Then it does not give the "ReferenceError: Can't find variable : window", but it does not even make the schema on the browser(all browser).
But if I remove the options parameter and let the library choose for itslef the size and mechanism. Then it works well in chrome and gives the "ReferenceError: Can't find variable : window" on Safari Chrome Version (45.0.2454.101 m) Mac OS X Yosemite - Safari 9.0(10601.1.56.2) Demo : http://52.24.87.119/demo/index.html - without options parameter http://52.24.87.119/demo/index2.html - with options parameter passed
@swapnil0545 Could you check again with the recent patch?
https://storage.cloud.google.com/ydn-db-d1/1.3.4/ydn.db-isw-core-qry.js https://storage.cloud.google.com/ydn-db-d1/1.3.4/ydn.db-isw-core-qry-dev.js
Regarding silently failing when size
option is given, I will let it go until quota management API is ready for compatibility reason. size
option should not be used in modern browsers. According to new concept of quota management, app cannot ask for how much they need, the platform will directly negotiate with user for allow quota.
If you want to reduce WebSQL data usage, check out fixed option in store schema.
@yathit Thank you for the update. It is no more giving me the window reference error. But It is still not creating the schema on all browsers when I pass
var options = {
mechanisms: ['websql'], // default ordering
};
to storage options. It is not just the size option. Here is the demo for that using 1.3.4 http://52.24.87.119/demo2/index.html
Do you want me to create a new ticket to handle that?
WebSQL may not be available in web worker.
That's sad, I just happen to come across a thread https://code.google.com/p/chromium/issues/detail?id=434740
Confirmed that Chrome has dropped support for websql inside worker proccess earlier only. It was not a problem as we were using iDB only.
But seems like in latest Safari update removed it too, because till then we were able to use it within the webworker, and we did not use indexedDB on iOS as it was buggy when we tried during iOS 8.
Yes. That is very sad news. My hope was Apple will fix indexeddb in ios 9, but still not there yet.
Even indexedDB is not available inside webworkers https://bugs.webkit.org/show_bug.cgi?id=149953
I don't know what safari developers are thinking. This is going to break our code with the latest updates, with no option to fix.
With database async parallel processing are already seperate from ui thread and web worker is not necessary. Just move over all process that use db to main thread. You will find it is better then web worker.
Yathit,
We desperately need to use the webWorkers. We are syncronizing data between the browser and our web server as a background process. Every aspect of modern web design would say to NOT use the main thread for any db access. Is there any way you can fix your library so that it will work properly with the web workers? We have a large number of users that are completely stopped without that feature. (Swapnil works on our product.)
The issue should fix now.
When I was trying to use the ydn-db in web-worker process, I found that there are many places where window object is being used.
However worker process do not allow usage of window in it, so we cannot use the library in worker.
Secondly, it is not recommended to use console objects in worker for logging, making it difficult to use the ydn in worker.However console works in chrome webworker but not in safari webworker.
I request to make one library where dom objects(window) and console is not used.