just needed your expertise in a general coredata Q.
How would u approach this problem?
App (v1.0) with pre-populated data. (model with 8 entities) - (SQLite db)
user can read/write in four of them while the rest (4) are read only and are pre-populated)
(so far so good)
Now App is updated (v1.1) with NEW pre-populated dataset (newSQLite db is provided)(NO CHANGES to the model)
How do you approach this and preserve USER data?
my approach:
1.delete the entities (the 4 that are read only)
2.replace them with the new entities
3.theoretically user data are intact.
4.build and run
is there something wrong with this?
What would you suggest?
thanks
If the readonly and readwrite entities do not share relationships, the easiest solution is to put each group in their own configuration and then have separate stores. That way, updating is just a matter of swapping out the readonly persistent store file.
If they do have relationships, then your only option is delete all the existing readonly and repopulate by building new objects on the fly.
If you are designing from scratch the first option is usually best for pre-populated material. You can use objectIDs and/or fetched relationships to form pseudo-relationships across stores.
Related
I evaluating CouchDB & I'm wondering whether it's possible to achieve the following functionality.
I'm planning to develop a web application and the app should allow a 'parent' table and derivatives of this table. The parent table will contains all the fields (master table) and the user will selectively choose fields, which should be saved as separate tables.
My queries are as follows:
Is it possible to save different versions of the same table using CouchDB?
Is there an alternative to creating child tables (and clutter the database)?
I'm new to NoSQL databases and am evaluating CouchDB because it supports JSON out of the box and this format seems to fit the application very well.
If there are alternatives to NOT save the derivatives as separate tables, the better will the application be. Any ideas how I could achieve this?
Thanks in advance.
CouchDB is a document oriented database which means you cannot talk in terms of tables. There are only documents. The _rev (or revision ID) describes a version of a document.
In CouchDB, there are 2 ways to achieve relationships.
Use separate documents
Use an embedded array
If you do not prefer to clutter your database, you can choose to use option (2) by using an embedded array.
This gives you the ability to have cascade delete functionality as well for free.
I have 2 lotus notes databases which have basically the same information: employee data. As there are too many documents, our team thought it would be better to have all data splitted in two DBs. Also, data of both databases use a form with the same name and design, called frmEmployeeInfo.
The client wants a third database with a view that will contain data (documents) from both databases I mentioned before. I know I can use, for example, outlines to open a view of another database but...is it possible to create a view in this third database that shows documents from other 2 DBs? I'm not sure if this is 'doable'. I don't want to copy documents from the databases into this 3rd. database because I think the database will be very slow, as there will be a lot of documents.
Do you have any kind of suggestion about how can I do it?
Thank you in advance.
You can't do that in classic Notes. But you should be able to do it in XPages (or through a web interface you create).
How big is the database? I have Notes databases with millions of documents, I don't see a need to split them into two, that sounds like a terrible design if you want to access all documents easily.
I would like to make a backup copy of my Core Data database, without using either the File Manager to make a copy of the sqlite file, or using the Persistent Store Coordinator's migratePersistentStore method (for reasons that are too long to explain here). What I want to do is to open a new persistent store with the same MOMD as the original file, create a new Managed Object Context, then iterate over all the objects in my database and insert them into the new context.
This will work for simple entities, but the problem is that my model has about 20 entities, many of them with one-to-many and many-to-many relationships. The slightly more complex solution would be to insert every object into the new MOC, and then hold all the new Managed Objects in memory and use them to tie up all the relationships between the objects in a subsequent passes. But it seems like a really messy solution.
Is there a clean, elegant way to achieve this, that might work for any kind of data model, not just a customized solution for my own model, and without having to hold every object in memory at the same time?
Thanks.
Copying the persistent store is far and above the easiest way to do this – I'd suggest revisiting your reasons against it or explaining what they are.
Copying objects from one context to another – from one on-disk persistent store to another – doesn't necessarily hold them all in memory at the same time. Core Data can turn them into faults.
I am new with Core Data and wanted to know if I should use it or not. I want an entity to only have one record which has a bunch of attributes. Should I be using something else or is Core Data fine for this?
For example: I have a user's home entity and it has a bunch of attributes about the house, but I expect the user to have only one home.
You should make your model class to be NSCoding compliant and store it on NSUserDefaults. Using core data to store only one record brings the overhead of the core data stack, and it's a hefty price for only 1 record.
We're looking into using CouchDB/CouchCocoa to replicate data to our mobile app.
Our system has a large number of users. Part of the database is private to each user -- for example their tasks. These I've been able to replicate without problem using filtered replication.
Here's the catch... The database also includes shared information only some of which pertains to a given user. How do I selectively replicate that shared information? For example a user's task might reference specific shared documents. Is there a way to make sure those documents are included in the replication without including all the shared documents?
From the documentation it seems that adding doc_ids to the replication (or adding another replication with those doc ids) might be one solution. Has any one tried this? Are there other solutions?
EDIT: Given the number of users it seems impractical to tag each shared document with all the users sharing it but perhaps that's the only way to do this?
Final solution mostly depends on your documents structure, but currently I see two use-cases:
As you keep everything within single database, probably you have some fields set to recognize, that document is shared or document is private, right? Example:
owner: "Mike"
participants: [] // if there is nobody mentioned, document looks like as private(?)
So you just need some filter that would handle only private documents and only shared ones: by tags, number of participants, references or somehow.
Also, if you need to replicate some documents only for specific user (e.g. only for Mike), than you need special view to handle all these documents and, yes, use replication by document ids, but this wouldn't be an atomic request: you need some service script to handle these steps. If shared documents are defined by references to them, than the only solution is the same: some service script, view that generated document reference tree and replication by doc._id's.
Review your architecture. Having per user database is normal use-case for CouchDB and follows way of data partitioning and isolation. So you may create per user database that would be private only for that user. For shared documents you may create additional databases playing with database members of security options. Each "shared" database will handle only certain number of participants by names or by groups, so there couldn't be any data leaks unless that was not a CouchDB bug(:
This approach looks too weird from first sight, but everything you've needed there is to create some management script that would handle database creation and publication, replications would be easy as possible and users data is in safe.
P.S. I've supposed that "sharing" operation makes document visible not for every one, but for some set of users. If I was wrong and "shared" state means "public" state than p2. will be more simpler: N users databases + 1 public one.