I have an app, using Core Data with a SQLite store.
At some point I'd like to remove all objects for a few entities. There may be close to a thousand objects.
From what I can tell via google and the official docs, the only way to delete objects is to [managedObjectContext deleteObject:(Entity *)] for every object. But this means that I must first fetch all objects.
The data store is just sqlite, is there no way to simply pass a TRUNCATE TABLE ZENTITY; to it?
If you relate your objects to a parent entity simply delete the parent. If your parents delete rule is set to 'cascade' all of those (1k) children will be removed as well.
John
The issue is that CoreData isn't just a SQLite wrapper. It's an object graph management solution and it stores cached versions of your object in memory in addition to other stuff. As far as I know to remove all instances of a given managed object you'll have to fetch them and then delete each. This isn't to say that this functionality shouldn't exist, because it probably should.
Have you actually tried it and found it to be a performance issue? If so, then you could provide some information showing that, and more importantly file a bug report on it. If not, then why are you bothering to ask?
It's not as simple as doing a TRUNCATE TABLE ZENTITY; since Core Data must also apply the delete rule for each object (among other actions), which means doing a fetch. So they may as well let you make the fetch and then pass the results into the context one-by-one.
Related
I have a cloudant database with a lot of deleted docs. Since they can't be destroyed, I would like to make a filtered copy with the non deleted items to a temporary base, destroy the original one, and copy the temporary base to a fresh database with the same name as before.
The problem is when I destroy the base, the API keys generated are also destroyed...
So the front app calling the new base can't acces it !
I would like to manually create a user/password, so I can recreate the same user each time I destroy the database.
I don't know how to do it ?
Or is there another way to achieve my goal ??
To answer your actual question, you can't add "users" to a Cloudant account, only databases. You can, however, make API-keys that span multiple databases, which sounds like it could be what you want:
https://dx13.co.uk/articles/2016/04/11/using-a-cloudant-api-key-with-multiple-cloudant-databases-and-accounts/
But as was noted by bessbd above, if your data model relies on document deletion, you're working against the grain of Cloudant, and sooner or later you'll end up with problems.
And finally -- the doc links appear to work just fine.
Maybe some useful stuff here: https://blog.cloudant.com/2019/11/21/Best-and-Worst-Practices.html
[disclaimer, I wrote that]
Can you please expand a little further on your use case? Why do you want to get rid of the deleted docs? Is there a way to avoid deleting the docs? Also, have you already read https://cloud.ibm.com/docs/services/Cloudant?topic=cloudant-documents#tombstone-documents ?
I am working on VB.NET project using Entity Framework 4.
When I create new entity and add it to context.EntityCollection, without calling context.SaveChanges I cannot found newly added entity in that collection.
I need to check for duplicate records before saving to database and it appears that only working solution is to store entities in some dictionary outside of whole EF-generated stuff for checking duplicate records.
Is there any better solution?
Checking database directly before saving changes is possible solution.
I have an entity called "Orders". What the best way to delete all of the orders? I know that I can query them and delete them one by one and then call save on the context, but is there a better, maybe more efficient proper way of doing this?
THnaks!
Nope, that's how you do it. Despite it usually using a database as a back-end data store, CoreData itself is not a database, it's a relational object graph manager. As such, there's no way to delete objects without actually fetching them and telling the context to delete them.
I am wondering which one I should use in this situation. I have a dropdown list that send a value back to the server. The server currently uses load and make the object. It then grabs a value out of and tries to convert it to an enum.
After doing some reading it seems that I should just use Get as I am need to access something out of the object other than the PK.
In general, use Get if you need access to properties other than the Id itself; this makes the intention of your code much clearer and is likely more efficient in the long run. Load is great if you need to setup FK relationships when creating or updating entities without making unnecessary round-trips to the database.
For further reading, check out Ayende's article that describes this in greater detail.
Get and Load are different if lazy loading is enabled.
If you use the method Load, NHibernate does not retrieve the entity from the database, but rather creates a proxy object and the only populated property is the ID.
If you access to an other property, NHibernate will load the entity from the DB.
So in your case the best use should be Get.
Introduction
My iOS project ships with a Core Data persistent store weighing some 160MB in SQLite format. There is a ton of grouped information in there, in which users should be able to mark favorites. For this, I need (at least part of) the database to have write capabilities. But of course persistent stores that ship in the application bundle are by design read-only.
If you want the store to have read-write capabilities, you should copy it to, e.g. the app's documents folder. I don't want to do this, because then the app would be twice the size, while the main part of that database is read-only anyway. That would be a waste of resources.
Multiple persistent stores for NSPersistentStoreCoordinator
This is why I thought of using two persistent stores. The first would be the big one in the bundle, and the second could be a small one in the documents folder, storing special "favorite" entities with relationships to the big store.
I know something is possible in this regard, but I can't find the specifics. Should one only use multiple stores if you also have multiple object models? Can one object model be 'distributed' over two persistent stores? When browsing through the Core Data Programming docs, I can't find any real reference about how to set this up. Also Marcus Zarra's book doesn't seem to delve into this topic:
It is possible to add more than one NSPersistentStore to the NSPersistentStoreCoordinator, which can be useful when dealing with data that is split into multiple files. However, in our exam- ple, we have a single file. (Marcus Zarra: "Core Data - Apple's API for Persisting Data on Mac OS X" page 71)
The Question
Who could tell me if what I'm thinking of is possible with Core Data and multiple persistent stores? And could you maybe provide a hint about how to achieve this? Online/offline resources that deal with the topic are very much appreciated too.
The answer is yes. #Caleb points to the right resources, but getting it to work is still quite awkward. I thought I'd place a resumé here:
For two NSPersistentStore instances to share the same model, you have to add a configuration to your model, which is a string-named subset of the entities:
In the model, to an entity that belongs to the second store, you add a fetched property (NSFetchedPropertyDescription for googlability). This is somewhat of a very simple stored procedure, and it could look like this:
Then, when you add the stores to your persistent store coordinator, you use the strings for the configuration argument (more info about the options here):
[persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"ModifyInBackground"
URL:storeURL1
options:options
error:&error]
[persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"ModifyInMain"
URL:storeURL2
options:options
error:&error]
Finally, when you want to get from the entity in store B to the entity in store A, you trigger the fetched property like you would trigger a fault, just by accessing it.
Note: A fetched property always returns an NSArray, because the predicate you write to establish the link might have multiple results. If you want to get to just one entity, you could place something like this in a wrapper method of your NSManagedObject subclass:
Wallpaper *recordedWallpaper = [record.wallpaper lastObject];
Yes, you may use multiple stores for a single model, but you can't create relationships between objects in different stores. Look for the Cross Store Relationships section in Core Data Programming guide, which says essentially that and recommends using fetched properties if you need to relate an object in one store to an object in another.
One thought: You might want to create different stores altogether and also different persistent store coordinators for each of the store. And then create different managed object contexts for each of model part. So let us say, I have a model with 3 entities: Student, college and courses. Suppose that I want to store Student and college entities in store1, and Course in Store2, I would have 2 sets of managedObjectContext, pesistent store and persistent cordinator. Now given that we can not have any cross store relatioinships, modification in one context do not effect another context. You dont have to create different models or associate them to stores -etc.