Anyone considered using Realm? We are extremely heavy CoreData users with our
own “DataStore” class to manage all the intricacies of CoreData, threading,
merging, migration, and so on.
After 5-6 years of CoreData, my next project I’m seriously considering not
using CoreData. Its turned into qui
In general, I agree with what’s been said so far.
About performance:
For the size of the object collection being described, I would tend to think
that the overhead of keeping track of it shouldn’t be a major factor, no matter
how you go… modern Mac’s and iOS devices have more than enough CPU po
On Aug 6, 2016, at 12:13 PM, Trygve Inda wrote:
>
>> On Aug 6, 2016, at 1:46 AM, Trygve Inda wrote:
>>> For example, I would need to add items with ID# 204, 765, 983, 124, and 458
>>> to the array. This seems like with Core Data it would be 5 different
>>> fetches. Or is there some efficient way
Do it, learn it, get familiar with it, build your libraries so you can do it in
more complicated cases much easier.
Use this as an opportunity to get used to Core Data, if you're not already.
Create a fork of your project in another branch and flesh out a Core Data
version to see what it's like
> To do it as one fetch you can set your predicate (or a sub predicate)
> as: [NSPredicate predicateWithFormat:@"%K in %@", primaryKey, keys] where
> primaryKey is the name of your ID property, and keys is an array of ID
> values which are "interesting" (as defined by the rest of your code).
>
Th
To do it as one fetch you can set your predicate (or a sub predicate)
as: [NSPredicate predicateWithFormat:@"%K in %@", primaryKey, keys] where
primaryKey is the name of your ID property, and keys is an array of ID
values which are "interesting" (as defined by the rest of your code).
On Sat, Aug 6
> On Aug 6, 2016, at 1:46 AM, Trygve Inda wrote:
>> For example, I would need to add items with ID# 204, 765, 983, 124, and 458
>> to the array. This seems like with Core Data it would be 5 different
>> fetches. Or is there some efficient way to fetch these 5 items in one
>> request?
>
> You coul
(Apologies to those getting this twice -- I sent from the wrong account the
first time.)
On Aug 6, 2016, at 1:46 AM, Trygve Inda wrote:
> For example, I would need to add items with ID# 204, 765, 983, 124, and 458
> to the array. This seems like with Core Data it would be 5 different
> fetches.
> Little different perspective, Core Data tends to work drop dead easy for
> simple stuff. Small data set with simple functionality should work straight
> out of the box easy.
>
> And there is nothing wrong with creating a manual array of managed objects
> from a Core Data result set.
Currently I
> On 6 Aug 2016, at 12:46 AM, Trygve Inda wrote:
>
> I am considering moving an app[…]
> Everything
> works.
So my question is: what is your motivation?
Is it underperforming?
Is it just idle curiosity, restlessness, too much time on your hands, or some
other state of mind? While I have s
Little different perspective, Core Data tends to work drop dead easy for
simple stuff. Small data set with simple functionality should work straight
out of the box easy.
And there is nothing wrong with creating a manual array of managed objects
from a Core Data result set.
I personally wouldn't s
On Aug 5, 2016, at 07:46 , Trygve Inda wrote:
>
> Somehow this seems easier to do without Core Data.
If you’ll accept my opinion as commentary and not anything more dire, I’d say
that your proposed course of action is based on several clearly undesirable
options:
1. For 5,000 records, I don’t
I am considering moving an app to Core Data. Currently it manages an array
of InterestingObjects. I use NSArrayControllers and TableViews. Everything
works.
I have two cases:
1. I have one array of all InterestingObjects and I set different predicates
on the array controller to show only those ma
13 matches
Mail list logo
