Core Data complications

Question

I'm refactoring and old app and was thinking of switching to core data. I have read previous threads here and on the web for the pros and cons compared to using directly sqlite or a wrapper. It still seems more direct to go with a sqlite wrapper because it seems to me that deviating from the standard use is either difficult or i cant find a efficient way to do it. For example having objects that dont get saved in the DB.Imagine a store where you could download a list of products and if one wanted a product he should save it locally . I read about 2 approaches one having seperate managed contexts and discarting the one with the temporary objects and also read about duplicating the model but they seem to me more as hacks for something that comes naturally when using sqlite directly.I also feel limited(maybe because of my inexperience with core data) at more complex queries . I know im not being very specific but i was looking for advice whether i could really benefit from going the distance migrating to core data when there is already a sqlite implementation.Frankly the temporary objects issue alone discourages me from switching but again maybe its my lack of knowledge.

Answer 1

There's nothing wrong with not using Core Data if you don't feel that it's appropriate for your application, or if you're just not comfortable with it, or if you're more comfortable with something else. So if using SQLite directly makes a lot of sense to you, go for it.

That said, if you're looking at Core Data as a drop-in replacement for SQLite, you're going to have trouble. When you use SQLite, you deal in tables and rows; when you use Core Data, you deal with objects and relationships. The Core Data framework maps those objects and relationships onto SQLite's tables (or some other persistent storage), so if you're translating objects back into tables in your head then you're sorta missing the point.