I'm using IndexedDB in a Windows 8 app and I'm very new to both. I've been able to successfully create, read, update, delete objects from object stores, and have created a couple databases and a few object stores. My question is how can I list all of my object stores and databases? I create a few bogus ones that are not needed and I would like to clean things up a bit, but I can't remember what they are named. Maybe this is anal retentive, but it seems like it should be possible to list all databases and stores. Thanks!
At the time of writing this post [chrome 72], You can list all the databases using following command in console of the browser. Essentially indexedDB.databases() is a Promise. You can use it to get list of all databases as an array. Run a loop on the array to get the names of databases.
indexedDB.databases().then(r => console.log(r))
Hope this helps
EDIT 2018 This answer is no longer applicable:
webkitGetDatabaseNames() is deprecated in chrome 60
In Chrome webkit there was a function which would return all database names, this function is no longer available as of Chrome 60 (webkitgetdatabasenames):
indexedDB.webkitGetDatabaseNames().onsuccess = function(sender,args)
{ console.log(sender.target.result); };
And there is another function which list all object stores in a single database which work in all browsers:
indexedDB.open(databaseName).onsuccess = function(sender, args)
{ console.log(sender.target.result.objectStoreNames); };
There is currently no way of enumerating the existing databases in the standard. Windows 8 apps use IE, which does not provide the non-standard webkitGetDatabaseNames method. You might be able to clear the databases using the options dialog in IE10.
Listing the stores inside a database is defined in the standard using the objectStoreNames method of an IDBDatabase instance.
Since all other topics reference back here as a duplicates. In Chrome you can view and delete all created databases in Developer Tools > Application > Storage.
To view IndexedDB internals: chrome://indexeddb-internals/
Related
I have a core data implementation. The stack is loaded using a NSPersistentContainer. During setup, I set the NSPersistentHistoryTrackingKey on the NSPersistentStoreDescription.
description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)
I'm trying to implement progressive migrations along this line https://williamboles.me/progressive-core-data-migration/ (fantastic article, by the way!)
The first problem I ran into was forcing checkpointing in the WAL. The code is pretty straightforward:
func forceWALCheckpointingForStore(at storeURL: URL) {
guard let metadata = NSPersistentStoreCoordinator.metadata(at: storeURL), let currentModel = NSManagedObjectModel.compatibleModelForStoreMetadata(metadata) else {
return
}
do {
let persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: currentModel)
let options = [NSSQLitePragmasOption: ["journal_mode": "DELETE"]]
let store = persistentStoreCoordinator.addPersistentStore(at: storeURL, options: options)
try persistentStoreCoordinator.remove(store)
} catch let error {
fatalError("failed to force WAL checkpointing, error: \(error)")
}
}
The problem occurs when the NSPersistentStoreCoordinator runs addPersistentStore. I get the following error:
Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store at url...
This makes perfect sense. The Core Data framework created additional tables (NSPersistentHistoryToken, NSPersistentHistoryTransaction etc..) that you have access to to manage changes in history. If you "open" or "access" the database without the history tracking option, the Core Data framework puts the database in Read Only mode to avoid data integrity issues.
As far as I can see in the documentation, the NSPersistentHistoryTrackingKey can only be set on the container, and not on the NSPersistentStoreCoordinator directly (via options).
Trying to stay "within the boundaries of the Container", I decided to call addPersistentStore (with the Pragmas Option) on the "persistentStoreCoordinator" property of the Container. The problem with this approach is that the container is instantiated with the latest version NSManagedObjectModel. Because we're smack bang in the middle of a migration process, the migration hasn't happened yet. Attempting to manipulate the store via the store coordinator inside the container in any way results in this error:
The model used to open the store is incompatible with the one used to create the store.
I had to therefore instantiate a container with the existing version of the model. Further research also revealed that I can force a WAL checkpoint via the NSPersistent container (and avoid having to use the coordinator) by setting the following option on the container description:
description.setValue("DELETE" as NSObject, forPragmaNamed: "journal_mode")
I created a temporary pre-migration container, instantiated it with the current (old) version of the managed object model, and set the above pragmas option to force a WAL checkpoint. It worked like a charm! The existing database was now ready to be migrated to the new model version(s).
The migration process kicks off and I hit a wall here:
NSMigrationManager.migrateStore(from: currentURL, sourceType: NSSQLiteStoreType, options: nil, with: mappingModel, toDestinationURL: destinationURL, destinationType: NSSQLiteStoreType, destinationOptions: nil)
Once again, we're back to the original problem:
Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store at url...
I want to migrate my database WITH the history tracking option enabled. After all, the history tracking tables created by the Core Data framework must also be migrated to the new version of the database. But, I don't know how to achieve this with the available Core Data classes. It is always best to stay as close to the vendor recommended implementations as possible and not do weird workarounds.
Here's what I know:
With lightweight migration options set on my Container, I can create new model versions to my heart's content!
With the NSPersistentHistoryTrackingKey also set on the same container, the Core Data framework automatically migrates my store from one model version to the next without missing a beat!
Therefore, if I now want to migrate my database manually with all the options set on the container, I should be able to do it because if Core Data can do it, I should be able to do it.... yes?
The documentation on these issues is a bit light. One of two things is happening here. Either the documentation is not updated OR ... I'm trying to do the weirdest thing known to man and it should never be done .... ever...
We have an Apex application (version 20.1) and our users must be able to change the database schema at runtime via button click (preferably without logging in again).
Currently we are solving this by installing our application multiple times, once per schema.
We recently discovered the function apex_export.get_application. We intend to use this function to bring our frontend under version control (finally!). We would like to deploy our application directly from the exported files. Having a single application, we would not have to mess with the internal component ids from the exported files.
Is it possible to install the application once and change the default schema via Pl/SQL code? Thank you!
I don't think this can be done, but perhaps the following is a reasonable compromise
add all the schemas you need to support to the workspace schema list
Any SQL (and I do mean any) in your app would be prefixed with an application item, eg
Before: select * from my_table
After: select * from &my_schema..my_table
At login time (or when a user selects it) you modify the MY_SCHEMA application item
(I've not tried this...so test/tread carefully)
Let's say I want to show two WkWebView side by side, each logged in to the same website, but with two different accounts. The logins (and other data) should be persisted between launches
According to this 2017 wwdc talk, it can be done. This is the result I get: they share data.
And this is what I want, not sharing data.
According to the speaker, it's possible. He just doesn't say how.
A few approaches I've tried
Instantiating a new WkWebView. That made no difference. They still share data. I tried instantiating both from a storyboard and in code.
Changing my bundle identifier. Not a viable solution as I want the two datastores to run side by side. But it works, and also it seems the data (sans cookies) is stored in /Users/username/Library/WebKit/(bundle-identifier)
Instantiating a new WKProcessPool with webView.configuration.processPool = WKProcessPool(). Made no difference.
Handling cookies myself. This would be my last resort. I'd set the WKWebsiteDataStore to be the .nonPersistent() one, and save and delete cookies in my own store on open and close (the cookie observer doesn't trigger in nonPersistent). Bad in three ways: 1. I need a secure place to store them - (Keychain)? 2. It won't persist whatever the sites may have in Local Storage, 3: added work and complexity
After a research it seems that Meteor Sessions are reset after refreshing page or opening the website in new tab, i.e. they are not usual server-side sessions but something like global javascript variables on client-side. Some people advice to use AmplifyJS, but I'm not sure that it will work like usual session in other frameworks/languages and also it is a third party library, so is there any normal way to use sessions in Meteor, i.e. keep user-specific data on server?
At this moment I'm handling that by using custom Collections, but it is not an ideal way of doing that because it is needed to remove expired values from Collection manually, which makes additional troubles.
Yes this is correct. Despite the name Session is nothing like a cookie, but just a reactive form of a variable stored in a hashmap
To keep data persistent across tabs you need to use a Collections (as this is the only way to reactively share data across tabs) - Cookies can't work because they can't be made reactive as data needs to be sent to the server to notify the client when there is a change. There really wouldn't be another way at the moment as the publish/subscribe methods can only send down data from collections at the moment.
You can use your setup you have now with your custom collection. You can use a server side cron job to remove expired data (either with Meteor.setInterval or Tom Coleman's cron.
There is a package developed just for that: https://atmospherejs.com/u2622/persistent-session
After installation you can use the following functions to set sessions which are persistent:
//store a persistent session variable which is stored across templates
Session.setPersistent(key, value);
//same as above, but automatically deletes session data when user logs out
Session.setAuth(key, value);
I've tried the package and it works like charm.
I'm using the latest ASP.Net WebAPI Nightly builds (dated 2013-01-16).
I have a simple EF database first model at the moment that has two entities - Patients and Visits. Each patient can have many visits.
I'd like to be able to query for my list of patients and have the visits entities for each patient returned inline. I know that WebAPI's OData implementation doesn't yet support $expand. I'm hoping that just means that optional client-controlled expansion is not supported and that I can force expansion server-side.
At the moment I'm not getting any of the visits inline.
For example, my PatientController's() Get() method looks like
[Queryable(AllowedQueryOptions=AllowedQueryOptions.Supported)]
public override IQueryable<Patient> Get()
{
var query = this.entities.Patients.Include("Visits");
return query;
}
I've verified that the query executing against my database does indeed include the visit information.
To use a publicly available OData service as an example, if you use the service at http://services.odata.org/OData/OData.svc/, you can get a list of Suppliers. This is http://http://services.odata.org/OData/OData.svc/Suppliers.
You can also ask for a list of suppliers that includes the list of products using http://http://services.odata.org/OData/OData.svc/Suppliers?$expand=Products
Stepping through the ASP.NET code (via the symbols server) I've got to the System.Web.Http.OData.Formatter.Serialization.ODataEntityTypeSerializer and can see that it's CreatePropertyBag method, which builds up the list of properties to be serialized, just doesn't include the navigation properties, and they don't seem to be enumerated anywhere else apart from being written out as NavigationLinks.
I'm quite new to the ASP.NET world in general and have spent a week or so getting my head around the way things work (particularly with the changes made to OData at the end of 2012 and further changes made so far in 2013).
I suspect that if the ODataEntityTypeSerializer was to be modified (I'm happy to try) to embed this extra information in the appropriate spot (within each navigation link as an nested inline feed as best I can tell) then I'd be set.
Questions:
Have I overlooked something obvious and there's a flag I can set to turn on this behaviour? I can see why, if such a flag exists, it would be off by default (EF lazy loading and this flag wouldn't get on well)
If #1 is no, is there some other ODataEntityTypeSerializer that I could use? If so, how do I switch to it?
If #2 is no, any pointers for where I should start writing my own? Is there a place I can substitute in my own serializer or do I have to maintain my own fork of ASP.NET's Extensions project (as opposed to the Runtime project)
Thanks very much!
$expand is very high on our list of things to support for OData. But as far as I know, we don't have any flag to turn it on server-side. The formatter doesn't currently allow you to substitute your own serializers either. So I'm afraid your only option in the meantime is to create a fork and add support for $expand. If you manage to get it working, please consider sending a pull request our way:
http://aspnetwebstack.codeplex.com/SourceControl/network
You can try it already in webapi nightly builds.
Here is how to install it with nuget:
http://aspnetwebstack.codeplex.com/wikipage?title=Use%20Nightly%20Builds