Deleting objects on NSManagedObjectContext with CBLIncrementalStore

[Ben Tally]

Hello,

I have the core data Recipes example running with CBL 1.0beta3.1.

I noted a crash in the demo when deleting 2 recipes from the tableview, but pushed on to build a fresh core data app from scratch with the CBL backing store.

Everything went as planned until I hit the same behavior in my new app.

I am seeing the exact same crash in both apps upon saving the context after deleting a second object.

    <Ingredient: 0x9392930> (entity: Ingredient; id: 0x9381db0 <x-coredata://872D8956-8022-412E-A0E2-743F4DAC9B72-19507-00023766C1CF2604/Ingredient/pCBL4ACA955C-7DFA-40C8-AF86-55F869C9CE07-19507-00023766C3238B44> ; data: {

    "CBLIS_Rev" = "1-386793a3148491e86053266119254e45";

    amount = 1;

    displayOrder = 0;

    name = "One prebaked 9\" pastry dough";

    recipe = nil;

})

)}

[tdis]   locked:(null)

[tids]---------------- 

2014-05-12 00:03:45.646 Recipes[79332:60b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[1]'

Can anyone else reproduce this crash in the Recipe demo?  Simply delete 2 recipes one after the other.

-Ben

[Ragu Vijaykumar]

Yeah, this is why I didn't use it. I filed an issue on Github a while ago about it.

Issue #1

[Ragu Vijaykumar]

As an aside and personal opinion, I recommend just using the CouchbaseLite framework as is without it. I thought it would be faster to use that CoreData addon, but it also seemed to make the document store mimic the CoreData sqlite store with the way it handles relationships and objects, which was like hacking the NoSQL document style to mimic a SQL storage system (ironic since CBL was written to store NoSQL in SQLite on iOS). I found that everything is just simpler if you just keep to the CouchbaseLite system, and you can easily peruse the contents of your db with the CouchbaseLite Viewer, which is a lot easier to grasp the data in your store than using software like NaviCat to peruse the sqlite file from CoreData.

On Monday, May 12, 2014 12:24:54 AM UTC-7, Ben Tally wrote:

[Ben Tally]

My project starts and ends with CouchbaseLite.  I'm using a cblite file as my sole persistence. (no sqlite anywhere)

I have nice round trip running with CouchbaseLIte Viewer and CoreData.  Other than this one snag, everything works as expected across 4 test devices and a 3 node cluster.

I suppose I'll start learning the CouchbaseLite framework, but I still think the CoreData approach has legs.

--

[Ragu Vijaykumar]

Yeah, it is pretty cool. Hopefully the issue will be figured out. As a personal plug, if you are interested in using the Core Data model editor, but want to use CouchbaseLite only, I've written a model generator similar to the XCode Managed Object generator. Given a CoreData model file, it'll spit out all your CBLModel class files.

https://github.com/RVijay007/cblmodelgenerator

Also, if you are interested in nested models, where data is encapsulated by separate classes but all contained within one document, I have a fork that I keep in sync with the main repo that supports that. It works with the cblmodelgenerator as well.

https://github.com/RVijay007/couchbase-lite-ios

[Ragu Vijaykumar]

Also, I was wrong about it mimic'ing CoreData in how it stored relationships. Not sure why I thought that, but just wanted to correct myself.