Comment by seivan | Hacker News Reader

Comment by seivan | Hacker News Reader

Parent Full thread

1) How is this a problem?

2) I don't get this. Your model is tied to a context manager, even if they are mutable, you don't need to merge context throughout your base unless you want to.

3) They are not thread safe, the same way UIView isn't thread safe. Why would multiple managed context become out of sync unless you allow it? It's not difficult to deal with. Create a context in the queue you are in. Merge it when you're done.

4) You can use Core Data without persistent store and make it fully in memory and everything will work fine. You can even separate your memory context with multiple context managers. Separating your creates and your deletes and etc.

5) Fud. Write a wrapper, use existing wrappers.

6) Agree.

I am actually kinda curious what problems you've gotten into recently. I've seen Core Data be improved ever since I started using it in 4. I wish it had Cocoa bindings on iOS... but ah well. I've never had any concerns here.

I don't use it for complex stuff. Ironically I didn't use it for a graph though I was told it would be a perfect fit, i wasn't really sure how to traverse without pulling everything into memory. So ended up just using NSObjects and keyedarchiver. But I would be curious to see if someone more familiar with Core Data would have solved it with CD.

> 1) How is this a problem?

I touched on this in a peer comment, but it ties your hands in terms of doing rather normal things that would make for a better model API.

> 2) I don't get this. Your model is tied to a context manager, even if they are mutable, you don't need to merge context throughout your base unless you want to.

Using an immutable model makes concurrency far, far easier (among other things).

> 3) They are not thread safe, the same way UIView isn't thread safe. Why would multiple managed context become out of sync unless you allow it? It's not difficult to deal with. Create a context in the queue you are in. Merge it when you're done.

Like I said in reply to your other comment -- The difference is that the 'model' is what binds all of your code together. The constraints of Core Data therefor introduce tightly bound constraints on all your code.

> 4) You can use Core Data without persistent store and make it fully in memory and everything will work fine. You can even separate your memory context with multiple context managers. Separating your creates and your deletes and etc.

I think you're confusing what I mean by in-memory model and on-disk model.

The way one defines and represents on-disk storage is very different than in-memory storage: the data is persistent, it must remain accessible over time, the model must be versioned, and changes to the actual model definition must be applied as migrations between versions.

In-memory models, however, live only for the lifetime of a particular run of that application, may be modified freely, require no versioning, and require no migrations other than code refactoring.

By tightly binding these things together, Core Data creates the worst of both worlds: all the complexity and downsides of on-disk models with almost none of the flexibility and simplicity of in-memory models.

> 5) Fud. Write a wrapper, use existing wrappers.

That involves quite a bit more work than defining a simple class. Tools such as mogenerator are big, complicated, and a hassle. The point of Core Data is to save effort, but it generates more work and complexity.

> 6) Agree.

Well, at least we agree about something :)

Reply on news.ycombinator.com