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 On Tuesday, May 13, 2014 10:11:26 AM UTC-7, Ben Tally wrote: > > 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. > > -- > > On Monday, May 12, 2014 2:55:13 PM UTC-7, Ragu Vijaykumar wrote: >> >> 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: >>> >>> 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 >>> >>> -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/def667b3-4bc7-4734-9bf5-01999bdb2f53%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
