Re: Recommended way to save NSPredicates in Core Data store?

[Ken Thomases]

On Aug 15, 2018, at 6:15 PM, Demitri Muna  wrote:
> 
> I'm building an interface that contains an NSPredicateEditor (think iTunes 
> smart playlists), and I want to save the predicate in a Core Data store. What 
> is the recommended way to do this? Serialize the NSPredicate object and save 
> it as a blob? Break apart the predicate into one or more NSExpressions (left 
> hand value, operator, right hand value) and reconstruct the predicate? I can 
> think of several possibilities, but am wondering what is the path of least 
> resistance (and, I suppose, most binding-friendly!).

Serializing the predicate (using NSKeyedArchiver) seems obviously the right way 
to go.  Any other approach is just reinventing serializing it in a worse way.

You can create a custom value transformer (subclass of NSValueTransformer) to 
automatically archive and unarchive.  Use that on your binding.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Recommended way to save NSPredicates in Core Data store?

[Demitri Muna]

Hi,

I'm building an interface that contains an NSPredicateEditor (think iTunes 
smart playlists), and I want to save the predicate in a Core Data store. What 
is the recommended way to do this? Serialize the NSPredicate object and save it 
as a blob? Break apart the predicate into one or more NSExpressions (left hand 
value, operator, right hand value) and reconstruct the predicate? I can think 
of several possibilities, but am wondering what is the path of least resistance 
(and, I suppose, most binding-friendly!).

Cheers,
Demitri

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Multiple Documents, Core Data & NSFetchedResultsController

[Sam Smallman]

Hey, 

I’m stuck in a bit of a rut here…
I have a macOS Document Based Application using Core Data. 
Each document has its own Managed Object Context as created from the template 
NSPersistentDocument and is injected into the variety of model managers that 
need it throughout the app.

As a way of keeping track off all the changes and updating the UI I’m using 
NSFecthedResultsController and its delegate methods, particularly 
controller(_:didChange:at:for:newIndexPath:)

All works beautifully when a single document is open in terms of creating, 
editing and deleting managed objects. 
The problem occurs when I have more than one document. 
After creating a new object within one document, no other documents 
NSFetchedResultsController is notified of the change when an object is made in 
theirs.

I can confirm objects are being made with managedObjectContext.hasChanges
And check they are indeed the correct object with 
managedObjectContext.insertedObjects
And also interestingly when I add an observer for 
Notification.Name.NSManagedObjectContextObjectsDidChange I can log that change 
and see they are the correct object within the right context.
But for some reason, NSFecthedResultsController is not…

Would any of you have any clues I could chase down to figure this out.
Many thanks for your help in advance.

Sincerely

Sam
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating object graph in swift, Core Data or vanilla objects?

[Keary Suska]

In that case the only way to avoid having to remove objects first, that I can 
think of, is to create your own custom persistent store. It’s not too hard, and 
might be a better solution in the long run anyway.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

> On Mar 21, 2018, at 9:52 AM, Glen Huang <hey...@gmail.com> wrote:
> 
> Thanks for the suggestion Keary, but some view controllers only load portion 
> of the whole graph.
> 
> For example, in the home screen, I show a list of clubs, and when a user taps 
> a club, I show its members. Showing members shouldn’t wipe out the whole 
> graph, but I do would like to make sure its members are empty before I import 
> its member json.
> 
>> On 21 Mar 2018, at 11:46 PM, Keary Suska <cocoa-...@esoteritech.com> wrote:
>> 
>> Why not just use a different persistent store instance each time? An 
>> in-memory store shouldn’t be terribly expensive to create, and you can 
>> either keep or dispose of other stores as you need.
>> 
>> Keary Suska
>> Esoteritech, Inc.
>> "Demystifying technology for your home or business"
>> 
>>> On Mar 21, 2018, at 7:40 AM, Glen Huang <hey...@gmail.com> wrote:
>>> 
>>> Thanks for the suggestion Alex.
>>> 
>>> I’m not sure making attributes transient would work though, because the 
>>> objects themselves would still be persisted, you can still save the context 
>>> and fetch them back, only that they don’t contain any attributes, if I’m 
>>> not wrong.
>>> 
>>> By refreshing the object graph, do you mean updating managed objects 
>>> instead of deleting and creating? I thought about that, but it seems 
>>> something quite difficult to do, because I have to compare the json with 
>>> the graph and figure out what should be created/deleted/updated, and it 
>>> still requires me to create the graph from scratch when the store is empty. 
>>> That’s why I’m looking for ways to have a clean sheet before importing 
>>> json, so I only have one way to manage the object graph (tear down and 
>>> create from scratch).
>>> 
>>>> On 21 Mar 2018, at 9:27 PM, Alex Finkel <finkel.a...@gmail.com> wrote:
>>>> 
>>>> if you dont want to persist anything, why not make all the attributes 
>>>> transient?  But I would still persist, and just refresh the object graph 
>>>> with the response based on how often the data may change. 
>>>> 
>>>> On Wed, Mar 21, 2018 at 4:56 AM, Glen Huang 
>>>> <hey...@gmail.com<mailto:hey...@gmail.com>> wrote:
>>>> Hi,
>>>> 
>>>> I'm using Core Data as my model, but I don't want to actually persist 
>>>> anything. Anytime a view controller is shown, I load json data from my 
>>>> server and populate the store.
>>>> 
>>>> The problem is that objects in Core Data persist between view controllers, 
>>>> even with in-memory store type. But when I load json data, I’d like to 
>>>> have a fresh start. So it seems I need to remove existing objects first.
>>>> 
>>>> You might say I shouldn't use Core Data in this case, just use vanilla 
>>>> objects. But Core Data solves lots of problems, like no need to worry 
>>>> about memory leak for circular dependencies (my model is pretty complex, 
>>>> lots of many-to-many relationships etc), NSFetchedResultsController, etc. 
>>>> And with vanilla objects, when you have a many-to-many relationship, it’s 
>>>> seems it’s impossible to prevent memory leak:
>>>> 
>>>> class Club {
>>>> var people: [Person]
>>>> }
>>>> class Person {
>>>> var name: String
>>>> var clubs: [Club]
>>>> }
>>>> 
>>>> Array in swift always create strong reference if I’m not wrong, and the 
>>>> two arrays can create circular references.
>>>> 
>>>> If I go with Core Data, to easily delete objects and have a fresh start, 
>>>> one solution involves carefully setting up delete rule between object 
>>>> models and then deleting ones at the level I want, and hope it could 
>>>> cascade throughout, but the problem is that this approach is very error 
>>>> prone. If I misconfigure some delete rules, there won’t be any errors, 
>>>> still leaving some objects in the store.
>>>> 
>>>> I wonder what’s the best way to create object graph in swift without the 
>>&g

Re: Creating object graph in swift, Core Data or vanilla objects?

[Glen Huang]

Thanks for the suggestion Keary, but some view controllers only load portion of 
the whole graph.

For example, in the home screen, I show a list of clubs, and when a user taps a 
club, I show its members. Showing members shouldn’t wipe out the whole graph, 
but I do would like to make sure its members are empty before I import its 
member json.

> On 21 Mar 2018, at 11:46 PM, Keary Suska <cocoa-...@esoteritech.com> wrote:
> 
> Why not just use a different persistent store instance each time? An 
> in-memory store shouldn’t be terribly expensive to create, and you can either 
> keep or dispose of other stores as you need.
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
>> On Mar 21, 2018, at 7:40 AM, Glen Huang <hey...@gmail.com 
>> <mailto:hey...@gmail.com>> wrote:
>> 
>> Thanks for the suggestion Alex.
>> 
>> I’m not sure making attributes transient would work though, because the 
>> objects themselves would still be persisted, you can still save the context 
>> and fetch them back, only that they don’t contain any attributes, if I’m not 
>> wrong.
>> 
>> By refreshing the object graph, do you mean updating managed objects instead 
>> of deleting and creating? I thought about that, but it seems something quite 
>> difficult to do, because I have to compare the json with the graph and 
>> figure out what should be created/deleted/updated, and it still requires me 
>> to create the graph from scratch when the store is empty. That’s why I’m 
>> looking for ways to have a clean sheet before importing json, so I only have 
>> one way to manage the object graph (tear down and create from scratch).
>> 
>>> On 21 Mar 2018, at 9:27 PM, Alex Finkel <finkel.a...@gmail.com> wrote:
>>> 
>>> if you dont want to persist anything, why not make all the attributes 
>>> transient?  But I would still persist, and just refresh the object graph 
>>> with the response based on how often the data may change. 
>>> 
>>> On Wed, Mar 21, 2018 at 4:56 AM, Glen Huang <hey...@gmail.com 
>>> <mailto:hey...@gmail.com><mailto:hey...@gmail.com 
>>> <mailto:hey...@gmail.com>>> wrote:
>>> Hi,
>>> 
>>> I'm using Core Data as my model, but I don't want to actually persist 
>>> anything. Anytime a view controller is shown, I load json data from my 
>>> server and populate the store.
>>> 
>>> The problem is that objects in Core Data persist between view controllers, 
>>> even with in-memory store type. But when I load json data, I’d like to have 
>>> a fresh start. So it seems I need to remove existing objects first.
>>> 
>>> You might say I shouldn't use Core Data in this case, just use vanilla 
>>> objects. But Core Data solves lots of problems, like no need to worry about 
>>> memory leak for circular dependencies (my model is pretty complex, lots of 
>>> many-to-many relationships etc), NSFetchedResultsController, etc. And with 
>>> vanilla objects, when you have a many-to-many relationship, it’s seems it’s 
>>> impossible to prevent memory leak:
>>> 
>>> class Club {
>>> var people: [Person]
>>> }
>>> class Person {
>>> var name: String
>>> var clubs: [Club]
>>> }
>>> 
>>> Array in swift always create strong reference if I’m not wrong, and the two 
>>> arrays can create circular references.
>>> 
>>> If I go with Core Data, to easily delete objects and have a fresh start, 
>>> one solution involves carefully setting up delete rule between object 
>>> models and then deleting ones at the level I want, and hope it could 
>>> cascade throughout, but the problem is that this approach is very error 
>>> prone. If I misconfigure some delete rules, there won’t be any errors, 
>>> still leaving some objects in the store.
>>> 
>>> I wonder what’s the best way to create object graph in swift without the 
>>> risk of leaking memory, if Core Data is the way to go, is there any better 
>>> way to easily detect objects that I forgot to delete? Or is there a better 
>>> way that I can guarantee that the store is clean before importing json data?
>>> 
>>> Best,
>>> Glen
>>> ___
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
>>> <mailto:Cocoa-dev@lists.apple.com> <mailto:Cocoa-dev@lists.apple.com 
>>> <mailto:Cocoa-dev@lists.apple.com>>)
&

Re: Creating object graph in swift, Core Data or vanilla objects?

[Keary Suska]

Why not just use a different persistent store instance each time? An in-memory 
store shouldn’t be terribly expensive to create, and you can either keep or 
dispose of other stores as you need.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

> On Mar 21, 2018, at 7:40 AM, Glen Huang <hey...@gmail.com> wrote:
> 
> Thanks for the suggestion Alex.
> 
> I’m not sure making attributes transient would work though, because the 
> objects themselves would still be persisted, you can still save the context 
> and fetch them back, only that they don’t contain any attributes, if I’m not 
> wrong.
> 
> By refreshing the object graph, do you mean updating managed objects instead 
> of deleting and creating? I thought about that, but it seems something quite 
> difficult to do, because I have to compare the json with the graph and figure 
> out what should be created/deleted/updated, and it still requires me to 
> create the graph from scratch when the store is empty. That’s why I’m looking 
> for ways to have a clean sheet before importing json, so I only have one way 
> to manage the object graph (tear down and create from scratch).
> 
>> On 21 Mar 2018, at 9:27 PM, Alex Finkel <finkel.a...@gmail.com> wrote:
>> 
>> if you dont want to persist anything, why not make all the attributes 
>> transient?  But I would still persist, and just refresh the object graph 
>> with the response based on how often the data may change. 
>> 
>> On Wed, Mar 21, 2018 at 4:56 AM, Glen Huang <hey...@gmail.com 
>> <mailto:hey...@gmail.com>> wrote:
>> Hi,
>> 
>> I'm using Core Data as my model, but I don't want to actually persist 
>> anything. Anytime a view controller is shown, I load json data from my 
>> server and populate the store.
>> 
>> The problem is that objects in Core Data persist between view controllers, 
>> even with in-memory store type. But when I load json data, I’d like to have 
>> a fresh start. So it seems I need to remove existing objects first.
>> 
>> You might say I shouldn't use Core Data in this case, just use vanilla 
>> objects. But Core Data solves lots of problems, like no need to worry about 
>> memory leak for circular dependencies (my model is pretty complex, lots of 
>> many-to-many relationships etc), NSFetchedResultsController, etc. And with 
>> vanilla objects, when you have a many-to-many relationship, it’s seems it’s 
>> impossible to prevent memory leak:
>> 
>> class Club {
>>  var people: [Person]
>> }
>> class Person {
>>  var name: String
>>  var clubs: [Club]
>> }
>> 
>> Array in swift always create strong reference if I’m not wrong, and the two 
>> arrays can create circular references.
>> 
>> If I go with Core Data, to easily delete objects and have a fresh start, one 
>> solution involves carefully setting up delete rule between object models and 
>> then deleting ones at the level I want, and hope it could cascade 
>> throughout, but the problem is that this approach is very error prone. If I 
>> misconfigure some delete rules, there won’t be any errors, still leaving 
>> some objects in the store.
>> 
>> I wonder what’s the best way to create object graph in swift without the 
>> risk of leaking memory, if Core Data is the way to go, is there any better 
>> way to easily detect objects that I forgot to delete? Or is there a better 
>> way that I can guarantee that the store is clean before importing json data?
>> 
>> Best,
>> Glen
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
>> <mailto:Cocoa-dev@lists.apple.com>)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
>> <http://lists.apple.com/>
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com 
>> <https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com>
>> 
>> This email sent to finkel.a...@gmail.com <mailto:finkel.a...@gmail.com>
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev%40esoteritech.com
> 
> This email sent to cocoa-...@esoteritech.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating object graph in swift, Core Data or vanilla objects?

[Glen Huang]

Thanks for the suggestion Alex.

I’m not sure making attributes transient would work though, because the objects 
themselves would still be persisted, you can still save the context and fetch 
them back, only that they don’t contain any attributes, if I’m not wrong.

By refreshing the object graph, do you mean updating managed objects instead of 
deleting and creating? I thought about that, but it seems something quite 
difficult to do, because I have to compare the json with the graph and figure 
out what should be created/deleted/updated, and it still requires me to create 
the graph from scratch when the store is empty. That’s why I’m looking for ways 
to have a clean sheet before importing json, so I only have one way to manage 
the object graph (tear down and create from scratch).

> On 21 Mar 2018, at 9:27 PM, Alex Finkel <finkel.a...@gmail.com> wrote:
> 
> if you dont want to persist anything, why not make all the attributes 
> transient?  But I would still persist, and just refresh the object graph with 
> the response based on how often the data may change. 
> 
> On Wed, Mar 21, 2018 at 4:56 AM, Glen Huang <hey...@gmail.com 
> <mailto:hey...@gmail.com>> wrote:
> Hi,
> 
> I'm using Core Data as my model, but I don't want to actually persist 
> anything. Anytime a view controller is shown, I load json data from my server 
> and populate the store.
> 
> The problem is that objects in Core Data persist between view controllers, 
> even with in-memory store type. But when I load json data, I’d like to have a 
> fresh start. So it seems I need to remove existing objects first.
> 
> You might say I shouldn't use Core Data in this case, just use vanilla 
> objects. But Core Data solves lots of problems, like no need to worry about 
> memory leak for circular dependencies (my model is pretty complex, lots of 
> many-to-many relationships etc), NSFetchedResultsController, etc. And with 
> vanilla objects, when you have a many-to-many relationship, it’s seems it’s 
> impossible to prevent memory leak:
> 
> class Club {
>   var people: [Person]
> }
> class Person {
>   var name: String
>   var clubs: [Club]
> }
> 
> Array in swift always create strong reference if I’m not wrong, and the two 
> arrays can create circular references.
> 
> If I go with Core Data, to easily delete objects and have a fresh start, one 
> solution involves carefully setting up delete rule between object models and 
> then deleting ones at the level I want, and hope it could cascade throughout, 
> but the problem is that this approach is very error prone. If I misconfigure 
> some delete rules, there won’t be any errors, still leaving some objects in 
> the store.
> 
> I wonder what’s the best way to create object graph in swift without the risk 
> of leaking memory, if Core Data is the way to go, is there any better way to 
> easily detect objects that I forgot to delete? Or is there a better way that 
> I can guarantee that the store is clean before importing json data?
> 
> Best,
> Glen
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> <mailto:Cocoa-dev@lists.apple.com>)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
> <http://lists.apple.com/>
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com 
> <https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com>
> 
> This email sent to finkel.a...@gmail.com <mailto:finkel.a...@gmail.com>
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Creating object graph in swift, Core Data or vanilla objects?

[Glen Huang]

Hi,

I'm using Core Data as my model, but I don't want to actually persist anything. 
Anytime a view controller is shown, I load json data from my server and 
populate the store.

The problem is that objects in Core Data persist between view controllers, even 
with in-memory store type. But when I load json data, I’d like to have a fresh 
start. So it seems I need to remove existing objects first.

You might say I shouldn't use Core Data in this case, just use vanilla objects. 
But Core Data solves lots of problems, like no need to worry about memory leak 
for circular dependencies (my model is pretty complex, lots of many-to-many 
relationships etc), NSFetchedResultsController, etc. And with vanilla objects, 
when you have a many-to-many relationship, it’s seems it’s impossible to 
prevent memory leak:

class Club {
  var people: [Person]
}
class Person {
  var name: String
  var clubs: [Club]
}

Array in swift always create strong reference if I’m not wrong, and the two 
arrays can create circular references.

If I go with Core Data, to easily delete objects and have a fresh start, one 
solution involves carefully setting up delete rule between object models and 
then deleting ones at the level I want, and hope it could cascade throughout, 
but the problem is that this approach is very error prone. If I misconfigure 
some delete rules, there won’t be any errors, still leaving some objects in the 
store.

I wonder what’s the best way to create object graph in swift without the risk 
of leaking memory, if Core Data is the way to go, is there any better way to 
easily detect objects that I forgot to delete? Or is there a better way that I 
can guarantee that the store is clean before importing json data?

Best,
Glen
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Are Core Data to-many relationships nullable?

[David Catmull]

Apparently the answer is that they should be declared nullable. Even though
I've seen claims that the property will always return a set, apparently
it's also allowable to assign it to nil to clear it out.

On Thu, Oct 5, 2017 at 1:00 PM, David Catmull <davidcatm...@gmail.com>
wrote:

> I'm adding nullability notations to my Core Data classes for Swift
> interoperability, and I need to know whether the properties for to-many
> relationships should be considered nullable, or if they will always read as
> empty sets. Is there an authoritative answer for this?
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Are Core Data to-many relationships nullable?

[David Catmull]

I'm adding nullability notations to my Core Data classes for Swift
interoperability, and I need to know whether the properties for to-many
relationships should be considered nullable, or if they will always read as
empty sets. Is there an authoritative answer for this?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Richard Charles]

> On Jun 14, 2017, at 2:34 PM, Carl Hoefs  
> wrote:
> 
> I never understood why they killed off EOF.

Enterprise

NeXT provided products and services for business. Apple’s focus is on consumers.

--Richard Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Carl Hoefs]

> On Jun 14, 2017, at 12:26 AM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Jun 13, 2017, at 23:54 , Glen Huang <hey...@gmail.com> wrote:
>> 
>> what do you use instead of Core Data?
> 
> I ended up writing my own object graph framework. Interestingly, many parts 
> of the implementation fell naturally into the same mechanisms Core Data uses 
> (such as having client-facing and primitive versions of the same property.) 
> Unfortunately, because it manipulates the class metadata at runtime, this 
> framework is also fatally stuck in the Obj-C world, and I haven’t found an 
> alternative approach for Swift.
> 
>> Also I don't quite get the "can’t afford the therapy afterwards" part
> 
> I used Core Data for a major project — years ago, around the time Leopard 
> came out — and it was incredibly painful: 6 months of utter misery. It’s one 
> of those magical Apple technology solutions that’s clever as all get-out, but 
> totally inscrutable. Core Data doesn’t fulfill a design that’s documented 
> somewhere, its design is … whatever its implementation does. Sometimes that 
> makes sense, sometimes it doesn’t.
> 
> I think Core Data is great for Apple’s internal use (e.g. in older versions 
> of iTunes/iPhoto/Photos), and perhaps feasible for 3rd party developers if 
> you’re dealing with tens of thousands of objects (for performance reasons). 
> It may have become more usable over the years, but I promised myself I’d 
> never go near it again.

I never understood why they killed off EOF.

-Carl


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Jerome Krinock]

I’ve stuck it out with Core Data through several projects, but I *never* use 
Core Data’s validation because it usually raises exceptions as objects are 
being constructed, presenting inscrutable errors to the user.  So I can’t 
explain why your validate is not getting called.  But if you did fix it, 
you probably wouldn’t like the result.

Instead, invoke your validateWhatever with “manual” function calls, at points 
which you deem are appropriate.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Glen Huang]

Sorry to hear you had a bad experience with Core Data. I feel like it probably 
should be reimagined for Swift.

So far my use case has been light and it didn't bite my in the butt yet. But I 
did submit a few Core Data tickets to bugreport. Haven't received any replies 
from any of them yet. It's a bit discouraging. Sigh.

> On 14 Jun 2017, at 3:26 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Jun 13, 2017, at 23:54 , Glen Huang <hey...@gmail.com 
> <mailto:hey...@gmail.com>> wrote:
>> 
>> what do you use instead of Core Data?
> 
> I ended up writing my own object graph framework. Interestingly, many parts 
> of the implementation fell naturally into the same mechanisms Core Data uses 
> (such as having client-facing and primitive versions of the same property.) 
> Unfortunately, because it manipulates the class metadata at runtime, this 
> framework is also fatally stuck in the Obj-C world, and I haven’t found an 
> alternative approach for Swift.
> 
>> Also I don't quite get the "can’t afford the therapy afterwards" part
> 
> I used Core Data for a major project — years ago, around the time Leopard 
> came out — and it was incredibly painful: 6 months of utter misery. It’s one 
> of those magical Apple technology solutions that’s clever as all get-out, but 
> totally inscrutable. Core Data doesn’t fulfill a design that’s documented 
> somewhere, its design is … whatever its implementation does. Sometimes that 
> makes sense, sometimes it doesn’t.
> 
> I think Core Data is great for Apple’s internal use (e.g. in older versions 
> of iTunes/iPhoto/Photos), and perhaps feasible for 3rd party developers if 
> you’re dealing with tens of thousands of objects (for performance reasons). 
> It may have become more usable over the years, but I promised myself I’d 
> never go near it again.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Quincey Morris]

On Jun 13, 2017, at 23:54 , Glen Huang <hey...@gmail.com> wrote:
> 
> what do you use instead of Core Data?

I ended up writing my own object graph framework. Interestingly, many parts of 
the implementation fell naturally into the same mechanisms Core Data uses (such 
as having client-facing and primitive versions of the same property.) 
Unfortunately, because it manipulates the class metadata at runtime, this 
framework is also fatally stuck in the Obj-C world, and I haven’t found an 
alternative approach for Swift.

> Also I don't quite get the "can’t afford the therapy afterwards" part

I used Core Data for a major project — years ago, around the time Leopard came 
out — and it was incredibly painful: 6 months of utter misery. It’s one of 
those magical Apple technology solutions that’s clever as all get-out, but 
totally inscrutable. Core Data doesn’t fulfill a design that’s documented 
somewhere, its design is … whatever its implementation does. Sometimes that 
makes sense, sometimes it doesn’t.

I think Core Data is great for Apple’s internal use (e.g. in older versions of 
iTunes/iPhoto/Photos), and perhaps feasible for 3rd party developers if you’re 
dealing with tens of thousands of objects (for performance reasons). It may 
have become more usable over the years, but I promised myself I’d never go near 
it again.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Glen Huang]

You're the hero man!

I totally forgot about the @objc case in swift 4. After prefixing it to my 
validation method, it works!

And if you don't mind me asking, what do you use instead of Core Data? It's 
indeed not that friendly to swift (relationships being NSSet instead of 
Set etc). Also I don't quite get the "can’t afford the therapy 
afterwards" part, care to explain? (Sorry if that's a joke and I didn't get it)

Thanks.

> On 14 Jun 2017, at 2:41 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Jun 13, 2017, at 23:32 , Glen Huang <hey...@gmail.com 
> <mailto:hey...@gmail.com>> wrote:
>> 
>> n my case, the location attribute is actually defined on a parent entity 
>> (let's call it Parent), and it has two child entity (Child1 and Child2), I 
>> want location to be optional for Child1 but not for Child2. So I made 
>> location to be optional on Parent, and defined a validation rule on Child2 
>> to prevent nils.
>> 
>> Is that something possible to do in Core Data?
> 
> I don’t “do” Core Data any more (I can’t afford the therapy afterwards), but 
> I get the impression from the documentation that one way is to do 
> “cross-property” validation in some parent property.
> 
> Alternatively, put a required location property on Child2, and a *transient* 
> location property on the parent that retrieves the child property as 
> appropriate. (Indeed, you can put plain properties on your parent entity 
> class, and stay out of the CD model for this extra property.)
> 
>> But I tried to add this
>> 
>> func validateName(_ value: 
>> AutoreleasingUnsafeMutablePointer<AnyObject?>) throws {
>> print(value.pointee)
>> }
>> 
>> And only "succeed" was printed. So it seems the validation didn't run for 
>> name either.
> 
> I dunno. (See above under therapy.) Be careful with Swift 4, because methods 
> might not be inferred to be @objc any more. You might need to do something 
> explicit to get this method into the Obj-C runtime. Core Data is, 
> unfortunately, deeply stuck in the Obj-C world.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Quincey Morris]

On Jun 13, 2017, at 23:32 , Glen Huang <hey...@gmail.com> wrote:
> 
> n my case, the location attribute is actually defined on a parent entity 
> (let's call it Parent), and it has two child entity (Child1 and Child2), I 
> want location to be optional for Child1 but not for Child2. So I made 
> location to be optional on Parent, and defined a validation rule on Child2 to 
> prevent nils.
> 
> Is that something possible to do in Core Data?

I don’t “do” Core Data any more (I can’t afford the therapy afterwards), but I 
get the impression from the documentation that one way is to do 
“cross-property” validation in some parent property.

Alternatively, put a required location property on Child2, and a *transient* 
location property on the parent that retrieves the child property as 
appropriate. (Indeed, you can put plain properties on your parent entity class, 
and stay out of the CD model for this extra property.)

> But I tried to add this
> 
> func validateName(_ value: AutoreleasingUnsafeMutablePointer<AnyObject?>) 
> throws {
> print(value.pointee)
> }
> 
> And only "succeed" was printed. So it seems the validation didn't run for 
> name either.

I dunno. (See above under therapy.) Be careful with Swift 4, because methods 
might not be inferred to be @objc any more. You might need to do something 
explicit to get this method into the Obj-C runtime. Core Data is, 
unfortunately, deeply stuck in the Obj-C world.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Glen Huang]

Thanks for quick reply.

I guess i should provide the full context, sorry I was unclear.

In my case, the location attribute is actually defined on a parent entity 
(let's call it Parent), and it has two child entity (Child1 and Child2), I want 
location to be optional for Child1 but not for Child2. So I made location to be 
optional on Parent, and defined a validation rule on Child2 to prevent nils.

Is that something possible to do in Core Data?

I had an epiphany when you mentioned it's validated only if non-nil. So the 
validation only works when the attribute isn't nii? But I tried to add this

func validateName(_ value: AutoreleasingUnsafeMutablePointer<AnyObject?>) 
throws {
print(value.pointee)
}

And only "succeed" was printed. So it seems the validation didn't run for name 
either.


> On 14 Jun 2017, at 10:36 AM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Jun 13, 2017, at 19:10 , Glen Huang <hey...@gmail.com 
> <mailto:hey...@gmail.com>> wrote:
>> 
>> In the Core Data Xcode editor, I enabled optional for this attribute, but I 
>> expect this method will prevent the object from being saved when the it's 
>> location isn't set
> 
> I don’t understand this. If you made the “location” attribute optional, I 
> would expect it to be validated only if non-nil. If the location is never 
> set, it’s nil by default, so why are you expecting validation to occur?
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to validate Core Data attributes ? (example in official doc doesn't work)

[Quincey Morris]

On Jun 13, 2017, at 19:10 , Glen Huang <hey...@gmail.com> wrote:
> 
> In the Core Data Xcode editor, I enabled optional for this attribute, but I 
> expect this method will prevent the object from being saved when the it's 
> location isn't set

I don’t understand this. If you made the “location” attribute optional, I would 
expect it to be validated only if non-nil. If the location is never set, it’s 
nil by default, so why are you expecting validation to occur?

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

How to validate Core Data attributes ? (example in official doc doesn't work)

[Glen Huang]

Hi,

I'm trying to validate an attribute of a NSManagedObject, I create a 
transformable attribute called location, make it CLLocation, and define a 
method on the object:

   func validateLocation(_ value: 
AutoreleasingUnsafeMutablePointer<AnyObject?>) throws {
   if value.pointee == nil {
   fatalError("Location can't be nil")
   }
   }

Which is adapted from the official document. In the Core Data Xcode editor, I 
enabled optional for this attribute, but I expect this method will prevent the 
object from being saved when the it's location isn't set and the context is 
saved.

But when I do that, the method isn't even called. I can confirm by setting a 
break point in the method, and it never blocks.

Apart from the previous method, I add the following to func application(_:, 
didFinishLaunchingWithOptions launchOptions:)

   let context = persistentContainer.viewContext
   let foo = Foo(context: context)
   foo.name = "foo"
   // The following should fail, since we didn't provide location value
   try! context.save()
   print("succeed")

Where Foo has a name attribute of type string and the location attribute as I 
mentioned. In my case "succeed" prints in the console.

Did I do something wrong or is it a bug on the Core Data side?  

I'm using Xcode 9 beta on macOS 10.12.5, with Swift 4 and the new building 
system.

Thanks
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: I think I screwed up Core Data multi-threading rules.

[Quincey Morris]

On Feb 25, 2017, at 14:58 , Daryle Walker  wrote:
> 
> I thought the entire AppKit, which includes NSDocument, runs only on the main 
> thread. The exceptions are methods that specially state that they have a 
> multi-threaded mode.

Much stuff in AppKit must be called on the main thread, yes, and anything that 
affect the UI presentation we assume to require the main thread. And yes, many 
more recent APIs have a background-thread operational mode for (usually) parts 
of a larger functional process. However, there’s a third category, of stuff 
that does not apparently have any thread requirements beyond the basic need for 
thread safety of mutable data references.

The fact that the documentation for this save method explicitly states the need 
to invoke the completion handler on the main thread is a hint that the save 
method might be in this third category — not have any thread-related 
requirements of its own.

In addition, since it’s so easy to invoke a handler on the main thread, I’d say 
it’s safer to do so, than to rely on an assumption, however plausible.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: I think I screwed up Core Data multi-threading rules.

[Daryle Walker]

> On Feb 23, 2017, at 10:43 PM, Quincey Morris 
>  wrote:
> 
> On Feb 23, 2017, at 18:25 , Daryle Walker  > wrote:
>> 
>>>override func save(to url: URL, ofType typeName: String, for 
>>> saveOperation: NSSaveOperationType, completionHandler: @escaping (Error?) 
>>> -> Void) {
>>>// Save the message data to the store so any background contexts can 
>>> read the data later.
>>>do {
>>>try self.container.viewContext.save()
>>>} catch {
>>>completionHandler(error)
>>>return
>>>}
>>> 
>>>// Do the usual code, possibly even use a background thread.
>>>super.save(to: url, ofType: typeName, for: saveOperation, 
>>> completionHandler: completionHandler)
>>>}
>> 
>> I found out about this method from the Document guide docs. I have two 
>> questions about it.
>> 
>> 1. Is it OK to abort your override before the call to super if your 
>> pre-super code gets an error?
> 
> The catch block you’ve shown seems perfectly reasonable. Unfortunately, the 
> documentation says you can do anything you want before or after, but “be sure 
> to invoke super”, which probably makes you nervous. However, I think you can 
> assume it’s ok to return like that if an error preventing the save occurs. 
> Any other assumption seems too paranoid.
> 
> The documentation also says that the completion handler must be invoked on 
> the main thread, and I doubt you can assume that this save function is itself 
> necessarily invoked on the main thread. IAC, it’s only one extra line to 
> invoke the completion handler on the main thread, so I’d do that.

I thought the entire AppKit, which includes NSDocument, runs only on the main 
thread. The exceptions are methods that specially state that they have a 
multi-threaded mode. There are two methods on NSDocument, one each for reading 
and writing, that enable multi-threading that you have to override to return 
TRUE. If enabled, the background thread for writing is created within “save(to: 
ofType: for: completionHandler:)” and the one for reading within 
“NSDocumentController.openDocument(withContentsOf: display: 
completionHandler:)”.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: I think I screwed up Core Data multi-threading rules.

[Quincey Morris]

On Feb 23, 2017, at 18:25 , Daryle Walker  wrote:
> 
>>override func save(to url: URL, ofType typeName: String, for 
>> saveOperation: NSSaveOperationType, completionHandler: @escaping (Error?) -> 
>> Void) {
>>// Save the message data to the store so any background contexts can 
>> read the data later.
>>do {
>>try self.container.viewContext.save()
>>} catch {
>>completionHandler(error)
>>return
>>}
>> 
>>// Do the usual code, possibly even use a background thread.
>>super.save(to: url, ofType: typeName, for: saveOperation, 
>> completionHandler: completionHandler)
>>}
> 
> I found out about this method from the Document guide docs. I have two 
> questions about it.
> 
> 1. Is it OK to abort your override before the call to super if your pre-super 
> code gets an error?

The catch block you’ve shown seems perfectly reasonable. Unfortunately, the 
documentation says you can do anything you want before or after, but “be sure 
to invoke super”, which probably makes you nervous. However, I think you can 
assume it’s ok to return like that if an error preventing the save occurs. Any 
other assumption seems too paranoid.

The documentation also says that the completion handler must be invoked on the 
main thread, and I doubt you can assume that this save function is itself 
necessarily invoked on the main thread. IAC, it’s only one extra line to invoke 
the completion handler on the main thread, so I’d do that.

> 2. What should happen if your post-super code (which I don’t have in my 
> example) has an error? Do you drop it to oblivion? Or can you call the 
> completion handler?

Invoking the completion handler a second time sounds like a really terrible 
idea. I’d strongly advise you to put all your failable code before the super 
invocation, so the issue doesn’t arise ...

> Note that if the call to super has its own errors, then your post-super code 
> would make the handler be called twice.

… but I think you’re showing a conceptual error here. The super invocation will 
*always* call the completion handler, error or no error. It’s a completion 
handler, not an error handler. You can assume that the completion block will 
involve logic to exit NSDocument’s internal save machinery and state, so a 
second invocation is will probably crash and burn.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: I think I screwed up Core Data multi-threading rules.

[Daryle Walker]

> On Feb 23, 2017, at 1:56 AM, Daryle Walker  wrote:
> 
> I naively thought this was OK, multi-threading wise. It worked before I added 
> the “canAsynchronusly…” method to say TRUE for my main file type. When that 
> method is added, the save hangs the program.
> 
>>override func data(ofType typeName: String) throws -> Data {
>>guard typeName == Names.internationalEmailMessageUTI else { throw 
>> NSError(domain: NSOSStatusErrorDomain, code: unimpErr, userInfo: nil) }
>> 
>>// Save the current message data to the store so a background task 
>> can see it.
>>var messageID: NSManagedObjectID?
>>var savingError: Error?
>>let mainContext = self.container.viewContext
>>mainContext.performAndWait {
>>do {
>>try mainContext.save()
>>} catch {
>>savingError = error
>>}
>>messageID = self.message?.objectID
>>}
>> 
>>// Let the main interface continue.
>>self.unblockUserInteraction()
>>guard savingError == nil else { throw savingError! }
>>guard messageID != nil else { throw NSError(domain: 
>> NSCocoaErrorDomain, code: NSCoreDataError, userInfo: nil) }
>> 
>>// Write out the message data for externalization.
>>var result: Data?
>>let backgroundContext = self.container.newBackgroundContext()
>>backgroundContext.performAndWait {
>>let backgroundMessage = backgroundContext.object(with: 
>> messageID!) as! RawMessage
>>result = backgroundMessage.messageAsExternalData
>>}
>>return result!
>>}
> 
> I use the original and the background copy of the message only within each of 
> their respective contexts. Is the new persistent-container class not 
> thread-safe even for returning (new) contexts? Am I calling 
> “unblockUserInteraction” inappropriately? (I had that question in another 
> post.) Is it the way I handle throwing?

It seems that “data(ofType:)” REALLY means it when the main interface is 
blocked until “unblockUserInteraction()” is called. The whole method is called 
in an alternate thread, which means that any of your setup code (i.e. make an 
independent copy) that MUST be on the main thread has to be called somewhere 
else.

Fortunately, there is a somewhere else:

> override func save(to url: URL, ofType typeName: String, for 
> saveOperation: NSSaveOperationType, completionHandler: @escaping (Error?) -> 
> Void) {
> // Save the message data to the store so any background contexts can 
> read the data later.
> do {
> try self.container.viewContext.save()
> } catch {
> completionHandler(error)
> return
> }
> 
> // Do the usual code, possibly even use a background thread.
> super.save(to: url, ofType: typeName, for: saveOperation, 
> completionHandler: completionHandler)
> }

I found out about this method from the Document guide docs. I have two 
questions about it.

1. Is it OK to abort your override before the call to super if your pre-super 
code gets an error?
2. What should happen if your post-super code (which I don’t have in my 
example) has an error? Do you drop it to oblivion? Or can you call the 
completion handler? Note that if the call to super has its own errors, then 
your post-super code would make the handler be called twice.

Now I can keep all the save code in the same thread:

> override func canAsynchronouslyWrite(to url: URL, ofType typeName: 
> String, for saveOperation: NSSaveOperationType) -> Bool {
> switch typeName {
> case Names.internationalEmailMessageUTI:
> return true
> default:
> return super.canAsynchronouslyWrite(to: url, ofType: typeName, 
> for: saveOperation)
> }
> }
> 
> override func data(ofType typeName: String) throws -> Data {
> guard typeName == Names.internationalEmailMessageUTI else { throw 
> NSError(domain: NSOSStatusErrorDomain, code: unimpErr, userInfo: nil) }
> 
> // Note the message's ID so a background context can find it later.
> let messageID: NSManagedObjectID = self.message.objectID
> self.unblockUserInteraction()
> 
> // Write out the message data for externalization.
> var messageData: Data?
> let backgroundContext = self.container.newBackgroundContext()
> backgroundContext.performAndWait {
> let backgroundMessage = backgroundContext.object(with: messageID) 
> as! RawMessage
> messageData = backgroundMessage.messageAsExternalData
> }
> return messageData!
> }

I really hope “NSManagedObject.objectID" is a thread-safe property getter.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not 

I think I screwed up Core Data multi-threading rules.

[Daryle Walker]

I naively thought this was OK, multi-threading wise. It worked before I added 
the “canAsynchronusly…” method to say TRUE for my main file type. When that 
method is added, the save hangs the program.

> override func data(ofType typeName: String) throws -> Data {
> guard typeName == Names.internationalEmailMessageUTI else { throw 
> NSError(domain: NSOSStatusErrorDomain, code: unimpErr, userInfo: nil) }
> 
> // Save the current message data to the store so a background task 
> can see it.
> var messageID: NSManagedObjectID?
> var savingError: Error?
> let mainContext = self.container.viewContext
> mainContext.performAndWait {
> do {
> try mainContext.save()
> } catch {
> savingError = error
> }
> messageID = self.message?.objectID
> }
> 
> // Let the main interface continue.
> self.unblockUserInteraction()
> guard savingError == nil else { throw savingError! }
> guard messageID != nil else { throw NSError(domain: 
> NSCocoaErrorDomain, code: NSCoreDataError, userInfo: nil) }
> 
> // Write out the message data for externalization.
> var result: Data?
> let backgroundContext = self.container.newBackgroundContext()
> backgroundContext.performAndWait {
> let backgroundMessage = backgroundContext.object(with: 
> messageID!) as! RawMessage
> result = backgroundMessage.messageAsExternalData
> }
> return result!
> }

I use the original and the background copy of the message only within each of 
their respective contexts. Is the new persistent-container class not 
thread-safe even for returning (new) contexts? Am I calling 
“unblockUserInteraction” inappropriately? (I had that question in another 
post.) Is it the way I handle throwing?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Alex Kac]

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 quite a nice system - no doubt, but there are 
many behaviors with it that I end up fighting and I feel like I am constantly 
working around. Over the years its gotten better, but there are still issues 
with performance and highly complicated schemas.

I haven’t tried Realm, but I’ve delved into their docs every few weeks to see 
how its progressing and I don’t know if we’d be trading one set of problems for 
another, but it looks promising.

> On Aug 9, 2016, at 1:34 AM, Britt Durbrow 
>  wrote:
> 
> In general, I agree with what’s been said so far.
> 
> 

Alex Kac - El capitán


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Britt Durbrow]

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 power to 
make it disappear in the noise. What you do with it will dominate the 
performance of the resultant app - using a screaming fast record management 
system, collating high-resolution medical images and doing feature recognition 
on them is going to run a lot slower than a recipe list app that uses a dog 
slow record management system, for example.

However, in absolute terms, a custom-tuned solution will outperform a 
runtime-flexible general purpose solution like Core Data (and SQLite, which 
it’s usually running on top of). Assembling fetch requests takes resources 
(CPU, memory, and battery), and because they are interpreted they are slower 
than pre-compiled fetch operations.

For example, suppose that I have a bunch of interestingObjects and I want to 
fetch them from file storage by UUID; and I want to do this as fast as possible 
(all other concerns being secondary). The strategy that I think I would take is 
to create two files, one with a hash table of the UUIDs and offsets into the 
second file, which contains the serialized storage of the interestingObjects 
(and for maximum speed, I would forgo portability in favor of just keeping a 
binary image of the interestingObjects if possible: i.e, write raw structs to 
disk). I would also think about mmap-ing the files into my address space to 
eliminate read() and write() calls.

This would yield the bare minimum overhead to accomplish the goal; at the cost 
of flexibility and portability (and potentially development time, depending on 
how much difficulty one encounters adapting a general purpose solution to the 
specific problem, and how adept one is at doing this sort of raw data structure 
manipulation).

For Core Data to do the same thing, it must parse the data model, construct 
search predicates, translate them into SQL, and hand that off to SQLite; which 
must in turn parse the database structure and “compile” the SQL into an 
actionable set of search operations, interpret that to perform the search, 
assemble the results into it’s buffers, and hand that back off to Core Data; 
which must then translate the SQLite buffers into managed objects (again, 
parsing the data model), and only then can it return the result. Oh, and it’s 
got error checking at every step also.

The direct approach requires calculating a hash (for a UUID, that might be as 
simple as xor-ing the bytes up as 32-bit ints, and doing a modulo operation to 
fit the result to the size of the hash table - but, I have not profiled that 
myself, so I can’t necessarily recommend it - it’s just an example), performing 
some small number of comparisons (ideally, only 1, in the case of a hit on the 
first hash table bucket), and a bit of pointer arithmetic to get the location 
of the storage of the desired object; and doing whatever minimal construction 
is required to turn that stored struct into an actual live interestingObject - 
much less complexity than what Core Data (or any general-purpose system) goes 
through.

Before making any commitments, I would profile all of the choices available to 
you - the above discourse is just a general overview of things; and details 
(and optimizations) matter. Sometimes, the profiler turns up the darnedest of 
results… :-)
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Andy Lee]

On Aug 6, 2016, at 12:13 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
> 
>> On Aug 6, 2016, at 1:46 AM, Trygve Inda <cocoa...@xericdesign.com> 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 could add an entity to your data model that represents the custom
>> collection.  It would have an attribute that is a one-to-many relationship to
>> InterestingObject.  If you only have one of those manually-constructed 
>> tables,
>> your data store would only contain one instance of this entity.  That's
>> perfectly okay.
>> 
>> --Andy
>> 
>> 
> 
> I can't do that at run time though. I need the user to be able to build
> custom collections (like a custom iTunes playlist) that is a subset of the
> full collection but not by any simple predicate criteria.

You can certainly do it at runtime.  Core Data allows your program to 
manipulate object graphs and save the changes.  It would be very weak indeed if 
it could not model arbitrary collections of objects that the user can modify 
and save.

To clarify my suggestion:

Presumably your data model will have an InterestingObject entity, and you'll 
specify the InterestingObject class as the class for that entity.  ("Entity" 
and "class" are related but separate concepts in Core Data.)

You seem to be envisioning that your data model ONLY has that one entity.

I am suggesting you add another entity, something like CustomAlbum, with 
presumably a corresponding class also named CustomAlbum.  The CustomAlbum 
entity would have a one-to-many relationship to the InterestingObject entity, 
called something like interestingObjects.  You can put any InterestingObjects 
you want into an album's interestingObjects collection, whether 
programmatically or in response to user input, and of course you can save 
changes to the album.

I second the suggestions others have made to create a "play" project using Core 
Data, either from scratch or as an experimental, purely educational fork of 
your existing project.  You will learn much more efficiently what you can and 
cannot do, and you will get a better sense of whether you want to change how 
your app manages its data.

I would echo Graham Cox's question about what your motivation is.  If your 
goals do not include getting generally familiar with Core Data -- I mean, if 
you don't have an urgent reason to learn Core Data except for this project -- 
then maybe you don't have a strong reason to convert the app.  5000 objects 
doesn't sound like much (depends on the objects, of course), and it sounds like 
you are already comfortable loading them all into memory.  So maybe, as Graham 
says, "IIABDFI".

But maybe you anticipate your app's needs will scale far beyond 5000?  Or maybe 
you want some of Core Data's other features beyond straightforward object 
persistence?  Or maybe you anticipate your object model will grow more complex, 
and you want to use the Core Data model editor to help visualize that?  Or 
maybe you're thinking a Core Data approach will reduce the learning curve for 
new developers, who could use their existing knowledge of Core Data instead of 
having to learn your current persistence mechanism?  You haven't said, so we 
can only guess.

--Andy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Alex Zavatone]

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.

It's a perfect and low cost opportunity to gain competence in CD if you don't 
have it already.


On Aug 6, 2016, at 1:13 PM, Ryan Dignard wrote:

> 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, 2016 at 9:13 AM, Trygve Inda <cocoa...@xericdesign.com>
> wrote:
> 
>>> On Aug 6, 2016, at 1:46 AM, Trygve Inda <cocoa...@xericdesign.com>
>> 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 could add an entity to your data model that represents the custom
>>> collection.  It would have an attribute that is a one-to-many
>> relationship to
>>> InterestingObject.  If you only have one of those manually-constructed
>> tables,
>>> your data store would only contain one instance of this entity.  That's
>>> perfectly okay.
>>> 
>>> --Andy
>>> 
>>> 
>> 
>> I can't do that at run time though. I need the user to be able to build
>> custom collections (like a custom iTunes playlist) that is a subset of the
>> full collection but not by any simple predicate criteria.
>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/
>> conceptuallyflawed%40gmail.com
>> 
>> This email sent to conceptuallyfla...@gmail.com
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Trygve Inda]

> 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).
> 

Thanks for this. Any idea how efficient this is?

Currently I keep a dictionary of my objects which is keyed on the
"interestingField" (a UUID). To gather a user-defined set of them I use a
loop with something like:

for (NSString* uuidString in mySetOfUUIDS)
   [collectedArray addObject:[dict objectForKey:uuidString]];

I wonder how fast each would be if I were collecting 500 out of 5000
objects?





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Ryan Dignard]

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, 2016 at 9:13 AM, Trygve Inda <cocoa...@xericdesign.com>
wrote:

> > On Aug 6, 2016, at 1:46 AM, Trygve Inda <cocoa...@xericdesign.com>
> 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 could add an entity to your data model that represents the custom
> > collection.  It would have an attribute that is a one-to-many
> relationship to
> > InterestingObject.  If you only have one of those manually-constructed
> tables,
> > your data store would only contain one instance of this entity.  That's
> > perfectly okay.
> >
> > --Andy
> >
> >
>
> I can't do that at run time though. I need the user to be able to build
> custom collections (like a custom iTunes playlist) that is a subset of the
> full collection but not by any simple predicate criteria.
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/
> conceptuallyflawed%40gmail.com
>
> This email sent to conceptuallyfla...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Trygve Inda]

> On Aug 6, 2016, at 1:46 AM, Trygve Inda <cocoa...@xericdesign.com> 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 could add an entity to your data model that represents the custom
> collection.  It would have an attribute that is a one-to-many relationship to
> InterestingObject.  If you only have one of those manually-constructed tables,
> your data store would only contain one instance of this entity.  That's
> perfectly okay.
> 
> --Andy
> 
> 

I can't do that at run time though. I need the user to be able to build
custom collections (like a custom iTunes playlist) that is a subset of the
full collection but not by any simple predicate criteria.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Andy Lee]

(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 <cocoa...@xericdesign.com> 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 could add an entity to your data model that represents the custom 
collection.  It would have an attribute that is a one-to-many relationship to 
InterestingObject.  If you only have one of those manually-constructed tables, 
your data store would only contain one instance of this entity.  That's 
perfectly okay.

--Andy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Trygve Inda]

> 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 have an NSTableView tied to an NSArrayController. I manually
populate the array controller as needed with items from my master array.

With Core Data it seems the NSArrayController would be tied to the Managed
Context and while I could apply a predicate to filter the array controller,
manually populating it would be slow.

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?




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Graham Cox]

> 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 some sympathy for any of these “reasons”, 
they’re not usually a good reason for rewriting valuable code that works. For 
those cases, creating a new project that allows you to explore them hamlessly 
is likely a better idea.

IIABDFI.

—Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Luther Baker]

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 stray from Core Data until you hit pain points,
performance problems or functionality limitations.

Core Data is like autolayout in that, it generally works very well for
simple things (which it sounds like you're after).

Just my $0.02,
Luther

On Fri, Aug 5, 2016 at 3:57 PM Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:

> On Aug 5, 2016, at 07:46 , Trygve Inda <cocoa...@xericdesign.com> 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 think there’s enough data to justify using
> Core Data at all, given the amount of development pain you can expect. Core
> Data is famous for pain. Your project may be the exception, where
> everything goes smoothly and Core Data brings a smile to your face, but I
> wouldn’t bet on it.
>
> 2. For 5,000 records, you do need a storage solution. If non-local storage
> is possible, then I’d suggest you look very seriously at CloudKit. It’s
> what Apple did *instead* of making Core Data usable for mere mortals. You
> may still need some kind of local persistence, but if only a few hundred
> records are needed locally, keeping them (or enough of their properties to
> populate your table view) in RAM may be enough.
>
> 3. If you must have local persistent storage, then I’d suggest one of the
> 3rd party databases. I recommend these behind CloudKit only because over
> time 3rd party libraries tend to embroil you in update compatibility woes,
> whereas sticking with Apple software means you know where you stand with
> updates and backward compatibility.
>
> 4. NSXxxController is a glue object, which exists only to let you avoid
> writing code that’s largely boilerplate. IMO it’s a terrible mistake to it
> them as an app *design* element. These classes are pure implementation.
>
> 5. The NSXxxController functions of sorting and filtering have their
> counterparts in Core Data and also in any decent persistent storage system
> that has database-like semantics. No need to think about NSXxxController.
>
> 6. Depending on what is involved with your “interestingness” property (the
> one that defines the subset of 200 or so records), you may be able derive
> it in the NSTableView data source (by logically combining two groups of
> records), or by providing a derived property, or by using Core
> Data/database fetch predicates, or by storing something in the database
> itself. What you do depends on the complexity of the property, but none of
> the options need NSXxxController.
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com
>
> This email sent to lutherba...@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data or not

[Quincey Morris]

On Aug 5, 2016, at 07:46 , Trygve Inda <cocoa...@xericdesign.com> 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 think there’s enough data to justify using Core 
Data at all, given the amount of development pain you can expect. Core Data is 
famous for pain. Your project may be the exception, where everything goes 
smoothly and Core Data brings a smile to your face, but I wouldn’t bet on it.

2. For 5,000 records, you do need a storage solution. If non-local storage is 
possible, then I’d suggest you look very seriously at CloudKit. It’s what Apple 
did *instead* of making Core Data usable for mere mortals. You may still need 
some kind of local persistence, but if only a few hundred records are needed 
locally, keeping them (or enough of their properties to populate your table 
view) in RAM may be enough.

3. If you must have local persistent storage, then I’d suggest one of the 3rd 
party databases. I recommend these behind CloudKit only because over time 3rd 
party libraries tend to embroil you in update compatibility woes, whereas 
sticking with Apple software means you know where you stand with updates and 
backward compatibility.

4. NSXxxController is a glue object, which exists only to let you avoid writing 
code that’s largely boilerplate. IMO it’s a terrible mistake to it them as an 
app *design* element. These classes are pure implementation.

5. The NSXxxController functions of sorting and filtering have their 
counterparts in Core Data and also in any decent persistent storage system that 
has database-like semantics. No need to think about NSXxxController.

6. Depending on what is involved with your “interestingness” property (the one 
that defines the subset of 200 or so records), you may be able derive it in the 
NSTableView data source (by logically combining two groups of records), or by 
providing a derived property, or by using Core Data/database fetch predicates, 
or by storing something in the database itself. What you do depends on the 
complexity of the property, but none of the options need NSXxxController.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data or not

[Trygve Inda]

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 matching the predicate in a
table. (Think of this as an iTunes smart folder)

2. I manually insert some of the InterestingObjects into an array controller
to be shown in a table. (Think of this as an iTunes user-defined folder -
just dragging in random songs)

#1 seems easy to migrate to Core Data as the table will be bound to my
managed object context and I can use predicates to show different subsets.

How can I effectively do #2?

Each InterestingObject has an identifier that is a UUID so I could make a
predicate that just lists all the InterestingObjects I am colleting. Will
that be effective with perhaps hundreds of objects?

Without Core Data it is easy to just go through the array and pick out a
hundred, add them to a different array and display them.

Basically I have a core data store of 5,000 InterestingObjects. I have a
list of 200 UUIDs (remember, each InterestingObject has a UUID) and I need
to list these 200 InterestingObjects in a table.

In some cases I need to combine them, so how is the best way with Core Data
to show a table of:

- all the InterestingObjects where name= "Joe"
- plus all the InterestingObjects with these 200 UUIDs

I hope this is clear.

Somehow this seems easier to do without Core Data.

Thanks.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data, OutlineView, TreeController

[Quincey Morris]

On May 23, 2016, at 11:16 , Raimond Hettrich <sa...@onlinehome.de> wrote:
> 
> I have the following problem with the constellation 
> coreData-treeController-outlineView.

Well, you keep asking, and you keep getting no answer, because no one on this 
list knows the answer — the problem domain is too large even to guess where to 
look.

My intuition says the problem is unwanted duplication. Somewhere within the 
complex of components (Core Data, KVO, NS…Controller, table view plus whatever 
else) there is a pair of duplicate objects, which means your data model isn’t 
actually connected to the user interface presented to the user. This sometimes 
happens to developers who are new to Cocoa because it’s not always obvious 
whether objects are created programmatically (via code) or archivally (via IB 
design).

I think your next step is to try to make your problem smaller. (It might help 
to work in a copy of your project, if your debugging changes are destructive.) 
Try adding objects to your managed object context via code, and see whether 
those changes are saved.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data, OutlineView, TreeController

[Raimond Hettrich]

Hallo all,

I´m new in objective-c coding and I have the following problem with the 
constellation coreData-treeController-outlineView.

I’ve got an view based outlineView which shows an hierarchical tree. I can add 
a new row with the default values of my entities attributes. I can add new 
children's depended of which row is selected and I can delete the selected row.

This shows that the bindings coreData-entity -> 
treeController-managedObjectContext -> tableViewColumn-arrangedObjects -> 
tableViewCell-objectValue.name are correct an functional.

Also I can use the saveAction, which was automatically implemented by creating 
the new coreDataProject, but if I close and reopen the app my outlineView shows 
nothing. 

This is what the following logs return. 

BOOL savedOK = [[self managedObjectContext] save:];   -> 1
NSLog(@"has Changes %hhd", _managedObjectContext.hasChanges);   -> 0

Is there a need to add code to the saveAction? I know that in the constallation 
coreData-arrayController-tableView is no need to add extra code. Since weeks 
I’m looking for an answer and I can’t find it.  

Have anyone an idea, what’s going wrong?

Many thanks,
Raycord

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data user-defined fields

[Jerry Krinock]

In a similar situation, I defined one Property to represent both your Required 
(A, B, C) and User-defined properties, and wrote some business logic to ensure 
that the Required properties were always present.  A variation would be that 
this user-interfacing Property is a dependent property, connecting to the 
appropriate A, B, C or User-defined properties in the model via custom 
accessors.  Don’t forget +keyPathsForValuesAffecting.

In the user interface, I put one pair of [+][-] buttons at the bottom left of 
the table to add rows, and another pair of [+][-] buttons at the top right of 
the table to add columns.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data user-defined fields

[Trygve Inda]

I have a core data document-based app at the document level is a Core Data
type called Library, with a one to many relationship to type Element.

Element has a few properties but I want to allow the user to add others (of
type string only at this point).

So I have Element:

String name
String propA
String propB
String propC

I think I need to add a one-to-many

Set userProperties

And a UserProperty type would have two properties:

String propName
String propValue

When all this is displayed in a table bound with Core Data. I want a column
for propD (so a UserProperty with propName = "propD").

How do I show the values since I have to go:

element.userProperties, then get to propName = "propD" and then grab the
propValue?

Is it important to make sure all elements have this? I'd like users to be
able to enter values in the table.

Properties for propA, propB, propC are easy but I need to user to be able to
create a column for propD and add values for some (or all) elements.

Thanks,

Trygve



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using a Core Data model by itself

[Jerry Krinock]

> On 2016 Apr 28, at 13:23, Jens Alfke <j...@mooseyard.com> wrote:
> 
> So you can start out declaring the model classes like
>   @interface Message : NSObject 

Just to clarify, the reason why you must do this and not inherit from 
NSManagedObject is because the designated initializer of NSManagedObject is 
-initWithEntity:insertIntoManagedObjectContext:.  Using +alloc-init will raise 
an exception or something.

Although your intended “migration” plan is possible as Jens says, keep in mind 
while considering this that you will make some decisions in the initial design 
that you will later regret, particularly if your reason for not using Core Data 
to begin with is that you are not familiar enough with Core Data.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using a Core Data model by itself

[Jens Alfke]

> On Apr 28, 2016, at 10:56 AM, Daryle Walker <dary...@mac.com> wrote:
> 
> Can I use a CD model object without managed contexts nor persistent stores?

I’m pretty sure you can’t, but if you’re not doing anything fancy in your 
modeling, the classes will just be pretty vanilla classes with some properties.

So you can start out declaring the model classes like
@interface Message : NSObject 
@property NSString* subject;
@property Address* sender;
…
and implement the NSCoding methods to save and restore the persistent 
properties. Then you can save your “database” by archiving a root object that 
all your models are transitively reachable from, and reload the database by 
loading that archive.

When you move to Core Data, just change the declaration to
@interface Message : NSManagedObject
and in the implementation file take out the -initWithCoder: and 
-encodeWithCoder: methods. You’ll also need to add an “@dynamic” declaration 
for the persistent properties, so that NSManagedObject can bind them to the 
database.

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Using a Core Data model by itself

[Daryle Walker]

I'm planning a messaging app. I have in mind a message model class. In Phase 2 
I plan to be able to send messages. (Phase 1 is just loading and saving from/to 
disk.) I plan on using Core Data to handle the combo draft folder / outbox / 
sent folder, with a CD Managed object class for the messages.

The thing is that the Phase 1, non-CD, model would then be a duplication of 
work. The model is not database-ish, just dumb data, which is why I'm not using 
CD immediately. I also worried on the differences between the 
NsPersistentDocument and NsDocument models. Can I use a CD model object without 
managed contexts nor persistent stores?  (I'd manually translate the model 
to/from NsData during (de)serialization.)

Sent from my iPhone
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Is Core Data / NSAtomicStore only for data objects with IDs?

[Daryle Walker]

OK, I’m about to write a cool app. I’m thinking of using Core Data to handle 
the, well, data. I’ve been looking around for weeks on how to use NSAtomicStore 
to read/write data in “legacy formats.” I finally saw a guide by Apple today 
(referenced from the API page for NSAtomicStore). The classes assume you’ll be 
generating some ID data for your various nodes. My data is dumb; it has no 
database-ish IDs anywhere to use. I can’t just make up random UUIDs because the 
lookups have to be reversible and the format is too dumb to place any IDs. Does 
this mean that my quest has been for nothing, that I can’t use CoreData to 
directly serialize to/from my format?

I just said “directly” because I can still make a data model for my format. I 
just have to strip out any IDs when I serialize it to users. I can keep any 
internal IDs when I store object graphs in my app’s library folders. Of course, 
I can’t directly read in the format either; I have to read the data in 
separately, create a blank object graph, import the data in, and keep track of 
both the graph and original file’s URL when I need to save out (I’ll just 
export the graph to a new ID-less file and swap.).

The guide mentioned HTML and CSV examples, but didn’t show any. HTML I can 
understand; you can use something like DOM to address every node. I can’t see 
it with CSV, unless you use one of the fields to make an ID. Is that what Apple 
meant, or can you use Core Data with dumb, un-ID’d data?

(I can understand the “use NSIncrementalStore for Internet-based stores” claims 
too. The main database’s URL serves as the store’s ID, and the inner objects 
and attributes can be represented by sub-URLs and/or index paths.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Data not retained in document based core data app with cocoa bindings

[Jerry Krinock]

> On 2015 Oct 11, at 09:30, Richard Charles  wrote:
> 
>> On Oct 11, 2015, at 2:41 AM, Devarshi Kulshreshtha 
>>  wrote:
>> 
>> Looking for more clues :-|

Devarshi, I tried the kludge which Richard found on Stack Overflow 
(self.view.window.windowController.document.managedObjectContext), and it 
worked for me.  Here you can get the demo from github:

https://github.com/jerrykrinock/CoreDataDocStoryboard/tree/master

The only think you left out of your description is that the table view assembly 
in the Interface Builder library now as view cells, so to make it work for text 
you need to drop a text field cell onto the view cell and it magically becomes 
a text field cell.

> You may want to give up on storyboards and swift for the time being.

Well, at least give up in storyboards in a document-based Mac app.  I got 
interested in this because I could not believe that such a ludricously long 
binding

self.view.window.windowController.document.managedObjectContext

was the recommended approach.  But it is the best answer I’ve found so far.  
The problem is that the storyboard has these two scenes, “Window Controller” 
and “View Controller”, with no way to get a message between them, *and* your 
document only gets access to only *one* of them in -[NSStoryboard 
instantiateControllerWithIdentifier:].  However, you need access to both: the 
window controller, to display the window, and the view controller, to bind to 
your data model.  But neither Cocoa Bindings nor outlet connections can cross 
from one scene to the other.

I wonder if it possible to pass something in the segue which would be less of a 
kludge?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Data not retained in document based core data app with cocoa bindings

[Devarshi Kulshreshtha]

Thank you Richard, Jerry.

I tried this binding:
self.view.window.windowController.document.managedObjectContext
and verified by opening the saved xml document in TextEdit, it showed saved
info :) but when I am trying to open it using the created app,
'DocumentSample' in my case, it is not showing any data in opened window.

Looking for more clues :-|

On Sun, Oct 11, 2015 at 11:20 AM, Richard Charles 
wrote:

>
> > On Oct 10, 2015, at 12:34 PM, Devarshi Kulshreshtha <
> devarshi.bluec...@gmail.com> wrote:
> >
> > I am sure that I am missing something over here, looking for guidance.
>
> As instructed by Jerry delete the Document from your storyboard.
>
> Courtesy of Apple and Mike Swan bind the array controller parameters
> managed object context to the view controller with a model key path of
>
> self.view.window.windowController.document.managedObjectContext
>
>
> http://stackoverflow.com/questions/28184218/what-is-the-new-way-of-binding-an-nsarraycontroller-to-the-managed-object-contex
>
> Save the document as an xml file. Open with TextEdit and verify that the
> model data has been saved to disk. The data will be identified with
> something like id="z103".
>
> Unfortunately when you reopen the document the model data does not display
> in the table view, so there are more issues to be addressed.
>
> --Richard Charles
>
>


-- 
Thanks,

Devarshi
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Data not retained in document based core data app with cocoa bindings

[Richard Charles]

> On Oct 11, 2015, at 2:41 AM, Devarshi Kulshreshtha 
> <devarshi.bluec...@gmail.com> wrote:
> 
> Looking for more clues :-|

You may want to give up on storyboards and swift for the time being. There are 
a lot of older core data tutorials on the web that could possibly help you.

You might also try a book by Hillegass. The older versions are Cocoa, the newer 
one is Swift.

--Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Data not retained in document based core data app with cocoa bindings

[Devarshi Kulshreshtha]

I am trying to make a simple document based core data app using cocoa
bindings by following below steps:

*Step 1: *Selected the default template for a document based mac os x app
with core data as enabled

*Step 2:* It generated below files -

*a*. AppDelegate.swift
*b*. ViewController.swift
*c.* Document.swift
*d*. Main.storyboard
*e*. Document.xcdatamodel, etc

*Step 3:* Added an entity - MyColorPalette with an attribute - myColorName
of type string

*Step 4:* In Main.storyboard added a table view over view controller

*Step 5:* Dragged an 'ArrayController' object from library onto
ViewControllerScene

*Step 6:* Dragged an 'NSObject' object from library onto ViewControllerScene

*Step 7:* Changed class of 'NSObject' object to 'Document'

*Step 8:* Updated entity of ArrayController as - MyColorPalette and
managedObject as - Document.managedObjectContext

*Step 9:* Selected table view column and performed its value binding with
arrayController, controller key as - arrangedObjects and modelKeyPath
as myColorName

*Step 10:* Added two buttons - 'Add' and 'Delete', mapped respective 'add:'
and 'remove:' actions with 'ArrayController' object

Now when I am running the app and trying to add or delete it is working
perfectly, but when I am trying to save the document and then re-open it,
it is not showing the previously saved information.

I am sure that I am missing something over here, looking for guidance.

Here is the link to its source code at github:
https://github.com/Daemon-Devarshi/DocumentSample

-- 
Thanks,

Devarshi
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Data not retained in document based core data app with cocoa bindings

[Richard Charles]

> On Oct 10, 2015, at 12:34 PM, Devarshi Kulshreshtha 
>  wrote:
> 
> I am sure that I am missing something over here, looking for guidance.

As instructed by Jerry delete the Document from your storyboard.

Courtesy of Apple and Mike Swan bind the array controller parameters managed 
object context to the view controller with a model key path of

self.view.window.windowController.document.managedObjectContext

http://stackoverflow.com/questions/28184218/what-is-the-new-way-of-binding-an-nsarraycontroller-to-the-managed-object-contex

Save the document as an xml file. Open with TextEdit and verify that the model 
data has been saved to disk. The data will be identified with something like 
id="z103".

Unfortunately when you reopen the document the model data does not display in 
the table view, so there are more issues to be addressed.

--Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Data not retained in document based core data app with cocoa bindings

[Jerry Krinock]

Hello, Devarshi.

I think that adding the Document to your storyboard was a mistake.  To prove 
that, log self to console in Document's init function, and you will see that, 
when one document opens, *two* Document objects get created.  Your user 
interface is bound to one, and the persistent store is connected to the other 
one.  So that explains why changes made in your user interface do not persist.

So you should delete that Document from your storyboard.  Then, note that, in 
Document’s instantiateControllerWithIdentifier() function, a window controller 
with identifier "Document Window Controller” is instantiated and in the 
storyboard, in the Window Controller, in the Identity Inspector, Xcode has 
cleverly set the Storyboard ID to the same string, "Document Window 
Controller”.  So it looks to me as if things would work if you could bind your 
array controller’s managedObjectContext the window controller with key path 
document.managedObjectContext.  Unfortunately, Xcode does not offer that 
choice; I presume because Cocoa Bindings do not work across scenes?

The instantiateControllerWithIdentifier() will also allow you to instantiate a 
view controller instead of a window controller.  So I suppose that you could 
subclass NSViewController, add a ‘document’ property to it, set it to self in 
instantiateControllerWithIdentifier(), and then you could bind to 
document.managedObjectContext, as desired.

But that seems like an awful lot of trouble to go through for what should be a 
quite normal document-based app.  Someone please tell us the correct way to 
make this binding :)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is NSTreeController good with Cocoa Bindings and Core Data now?

[Jerry Krinock]

 On 2015 Aug 23, at 17:50, Dave Fernandes dave.fernan...@utoronto.ca wrote:
 
 It’s been working pretty well since Snow Leopard. Haven’t had any weird undo 
 issues in a while.

Thank you, Dave.  With the votes thus counted as 1 YAY and 0 NAY, I’ll give it 
a try :)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Is NSTreeController good with Cocoa Bindings and Core Data now?

[Jerry Krinock]

A long time ago, I was advised to use an old-fashioned data source on my 
outline views for Core Data trees, because NSTreeController did not work the 
way it should have.

Have those issues now been resolved now?  I’m working on a new app, with Core 
Data and Cocoa Bindings.  The new app will require OS X 10.10 or 10.11 minimum.

Thank you,

Jerry


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is NSTreeController good with Cocoa Bindings and Core Data now?

[Dave Fernandes]

It’s been working pretty well since Snow Leopard. Haven’t had any weird undo 
issues in a while.

 On Aug 23, 2015, at 4:56 PM, Jerry Krinock je...@ieee.org wrote:
 
 A long time ago, I was advised to use an old-fashioned data source on my 
 outline views for Core Data trees, because NSTreeController did not work the 
 way it should have.
 
 Have those issues now been resolved now?  I’m working on a new app, with Core 
 Data and Cocoa Bindings.  The new app will require OS X 10.10 or 10.11 
 minimum.
 
 Thank you,
 
 Jerry
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
 
 This email sent to dave.fernan...@utoronto.ca


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Converting SQL delete statement to Core Data

[Laurent Daudelin]

Since there is no Core Data specific list, I thought I would ask here.

I'm trying to convert the following SQL statement to Core Data:

delete from SomeTable
where someID not in (select someID from SomeTable group by
property1, property2, property3)

Basically, I want to retrieve and delete possible duplicates in a table
where a record is deemed a duplicate if property1, property2 and property3
are equal to another record.

How can I do that?

Thanks in advance!

-Laurent.
-- 
Laurent Daudelin laur...@nemesys-soft.com
AIM/iChat/Skype:*LaurentDaudelin*  http://www.nemesys-soft.com/
Logiciels Nemesys Software
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data Mapping Model and empty filter predicates

[Rick Mann]

I've run into an issue that I haven't seen before with our mapping models: If 
the filter predicate was set, and is then cleared, migration complains about 
the empty filter predicate with:

NSInvalidArgumentException: Unable to parse the format string 

I'm having to hand-edit the mapping XML files to remove the 
sourcefilterpredicatestring attribute tag altogether in order to make it 
happy.

Is this a bug introduced in Xcode 6.3.1, that emptying the editor Filter 
Predicate field leaves an empty XML tag, that the migration code can't handle? 
That's what seems to be happening, but I haven't checked against an older 
version of Xcode to see if it doesn't do that.

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data sync between iOS and Mac apps

[Kyle Sluder]

On Tue, May 12, 2015, at 10:35 AM, Jens Alfke wrote:
 You can still handle conflicts using Dropbox, it’s just trickier. You’ll
 need to detect the renamed version of the file that Dropbox creates —
 something like “MyAppData (Jens Alfke's conflicted copy 2015-05-09).db” —
 then open both files and reconcile any changes, then save back to the
 original file and delete the conflicted copy. And somehow keep both
 devices from doing this at the same time, or you’re back at square one.

There was a hilarious* bug in an early version of OmniPresence where
clients a) eagerly resolved conflicts and b) did not back off if their
attempt to resolve the conflict created another conflict.

The result was that if you had two Macs running OmniPresence, and you
managed to create a conflict, occasionally both machines would just
start generating infinite duplicates of the conflicted document.

--Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data sync between iOS and Mac apps

[davelist]

CloudKit does seem to be Apple’s answer going forward (which makes me suspect 
Core Data sync will not improve) but CloudKit requires internet access for the 
app to work at all which I don’t want to require.

I’m not sure I understand your concerns about Dropbox. The app is single user 
so when the iOS enters the background, I can upload the data (if there’s a 
network connection at the moment) for modified files to Dropbox. When the app 
starts I can check Dropbox (or warn the user that there may be a newer version 
on Dropbox if there’s no internet connection) to see if the document files are 
newer on Dropbox. It’s not as clean as a pure sync but gives the user more 
control over their data (which is important for my app).

Dave



 On May 10, 2015, at 1:37 PM, Alex Kac a...@webis.net wrote:
 
 I would try CloudKit. Its super simple and far simpler than using Dropbox. 
 Plus using Dropbox you end up with lots of issues going forward that you 
 don't want to mess with. Different database versions, data that is not 
 written to disk when you make the copy due to disk caches, and a lot more. 
 
 CloudKit is Apple's solution for sync between Apple devices. CoreData sync 
 over iCloud was never going to work well. I loved the idea, but as everyone 
 knows its implementation wasn't really foolproof. Many of us realized that 
 the better solution is a cloud sync that we designed ourselves. Apple 
 providing CloudKit solves that for Apple-only users. 
 
 
 
 On Sun, May 10, 2015 at 7:16 AM, davel...@mac.com wrote:
 
 Thanks MIchael. That's what I was afraid of (i.e., that Apple doesn't make 
 this straightforward). I first looked at BSManagedDocument 2-3 years ago but 
 never got around to trying it for my original app as I kept hoping Apple 
 would have an official solution to this problem.
 
 Also thanks to Jens Alfke for his reply about Couchbase Lite 
 (http://www.couchbase.com/nosql-databases/couchbase-mobile). I may look into 
 it but after skimming the site, I couldn't tell exactly what I would need 
 (i.e., would I need to setup my own server or use a server that your company 
 provides, etc.). I doubt my app would generate enough income to even cover 
 the server costs. My apps are for teachers and I write them because I want to 
 use them myself but they don't generate much money given the fairly narrow 
 target audience and that many schools provide systems the teacher has to use 
 for the tasks (i.e., my existing iOS apps, Attendance and Attendance2 are for 
 taking attendance in class and generating reports, etc.). Jens, I may send 
 you an email off-list with a few more questions (that you can ignore if you 
 want).
 
 I may just end up using Dropbox without sync (i.e., have the user send the 
 data to Dropbox from the iOS app) when they want to use it on the Mac and 
 import the data from Dropbox into iOS after the data has been changed on the 
 Mac. It's not elegant but it's better than risking data corruption via an 
 automatic sync that isn't reliable. Perhaps with some warnings about which 
 data is newer by looking at modification dates from the file metadata, it 
 could be usable. The app is mainly intended to be used on iOS but I want to 
 use the Mac for one or two features that would not work well on iOS.
 
 Dave
 
 
  On May 7, 2015, at 10:57 AM, Michael Swan michaels...@mac.com wrote:
 
  Dave,
  Unfortunately on the OS X side with iCloud, Core Data, and documents it is 
  pretty much a pick any two situation. The iOS side can be done but there 
  are some gotchas not really covered in the documentation. I've actually 
  just started work on my own custom subclasses of UIManagedDocument and 
  NSDocument (NSPersistentDocument is less than useless if you want to share 
  with iOS). My current plan is to use Apple's code as much as possible 
  without adding extra stores like Ensembles does. If you're interested we 
  could talk about a collaboration to build an open sourced set of classes to 
  handle this area. (I plan to include a file browser for iOS as well since 
  nothing currently exists.)
 
  On iOS you set two keys in the options dictionary to tell the system where 
  to keep the change logs and what the name should be. The name is typically 
  a UUID and the location is generally some version of ChangeLogs at the root 
  level of the ubiquity container. The catch is that your can't set those 
  options in configurePersistentStoreCoordinator… and have it come out right. 
  You have to init the document then set the persistentStoreOptions property 
  to a dictionary with those keys in order for the file package to get the 
  right structure. You also need to create the document locally first and 
  then move it to the ubiquity container.
 
  On OS X NSPersistentDocument can only make flat files, not packages like 
  UIManagedDocument (I've filed a bug about there being no counterpart to 
  UIManagedDocument for OS X, been open for over a year now…). 
  BSManagedDocument

Re: Core Data sync between iOS and Mac apps

[Jens Alfke]

 On May 12, 2015, at 6:00 AM, davel...@mac.com wrote:
 
 I’m not sure I understand your concerns about Dropbox. The app is single user 
 so when the iOS enters the background, I can upload the data (if there’s a 
 network connection at the moment) for modified files to Dropbox.

A single-user app is less likely to encounter conflicts, but it can still 
happen since many users have multiple iOS devices. I frequently end up 
switching from iPhone to iPad, sometimes even the same app (quickly check news 
on my iPhone, start reading an article, go upstairs and grab the iPad so I can 
read the article more comfortably…) And if your app doesn’t somehow deal with 
this, it’s looking at potential data-loss scenarios.

You can still handle conflicts using Dropbox, it’s just trickier. You’ll need 
to detect the renamed version of the file that Dropbox creates — something like 
“MyAppData (Jens Alfke's conflicted copy 2015-05-09).db” — then open both files 
and reconcile any changes, then save back to the original file and delete the 
conflicted copy. And somehow keep both devices from doing this at the same 
time, or you’re back at square one.

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data sync between iOS and Mac apps

[davelist]

Thanks MIchael. That's what I was afraid of (i.e., that Apple doesn't make this 
straightforward). I first looked at BSManagedDocument 2-3 years ago but never 
got around to trying it for my original app as I kept hoping Apple would have 
an official solution to this problem.

Also thanks to Jens Alfke for his reply about Couchbase Lite 
(http://www.couchbase.com/nosql-databases/couchbase-mobile). I may look into it 
but after skimming the site, I couldn't tell exactly what I would need (i.e., 
would I need to setup my own server or use a server that your company provides, 
etc.). I doubt my app would generate enough income to even cover the server 
costs. My apps are for teachers and I write them because I want to use them 
myself but they don't generate much money given the fairly narrow target 
audience and that many schools provide systems the teacher has to use for the 
tasks (i.e., my existing iOS apps, Attendance and Attendance2 are for taking 
attendance in class and generating reports, etc.). Jens, I may send you an 
email off-list with a few more questions (that you can ignore if you want).

I may just end up using Dropbox without sync (i.e., have the user send the data 
to Dropbox from the iOS app) when they want to use it on the Mac and import the 
data from Dropbox into iOS after the data has been changed on the Mac. It's not 
elegant but it's better than risking data corruption via an automatic sync that 
isn't reliable. Perhaps with some warnings about which data is newer by looking 
at modification dates from the file metadata, it could be usable. The app is 
mainly intended to be used on iOS but I want to use the Mac for one or two 
features that would not work well on iOS.

Dave


 On May 7, 2015, at 10:57 AM, Michael Swan michaels...@mac.com wrote:
 
 Dave,
 Unfortunately on the OS X side with iCloud, Core Data, and documents it is 
 pretty much a pick any two situation. The iOS side can be done but there are 
 some gotchas not really covered in the documentation. I've actually just 
 started work on my own custom subclasses of UIManagedDocument and NSDocument 
 (NSPersistentDocument is less than useless if you want to share with iOS). My 
 current plan is to use Apple's code as much as possible without adding extra 
 stores like Ensembles does. If you're interested we could talk about a 
 collaboration to build an open sourced set of classes to handle this area. (I 
 plan to include a file browser for iOS as well since nothing currently 
 exists.)
 
 On iOS you set two keys in the options dictionary to tell the system where to 
 keep the change logs and what the name should be. The name is typically a 
 UUID and the location is generally some version of ChangeLogs at the root 
 level of the ubiquity container. The catch is that your can't set those 
 options in configurePersistentStoreCoordinator… and have it come out right. 
 You have to init the document then set the persistentStoreOptions property to 
 a dictionary with those keys in order for the file package to get the right 
 structure. You also need to create the document locally first and then move 
 it to the ubiquity container.
 
 On OS X NSPersistentDocument can only make flat files, not packages like 
 UIManagedDocument (I've filed a bug about there being no counterpart to 
 UIManagedDocument for OS X, been open for over a year now…). 
 BSManagedDocument will create a file package that looks like a locally stored 
 UIManagedDocument but it doesn't have the logic for dealing with files in 
 iCloud (my current plan is to build a subclass of BSManagedDocument with the 
 extra logic in place).
 
 Apple's answer to me when I have asked about this in he past is that it is 
 possible to sync Core Data documents through iCloud but you have to do all 
 the heavy lifting (I have no idea if that will change in June, but I doubt 
 it).
 
 As far as entitlements go you just need the document option enabled and to 
 ensure that both apps use the same container.
 
 On the Mac the documents should show up in the normal open sheet just like 
 they do for TextEdit and Preview documents that are in the cloud.
 
 These guides are a good starting point:
 Document Based App Programming Guide for Mac
 Document Based App Programming Guide for iOS 
 iCloud Design Guide
 iCloud Programming Guide For Core Data
 
 Thanks,
 Mike Swan
 ETCP Certified Entertainment Electrician
 347-451-5418
 theMikeSwan.com
 
 On May 5, 2015, at 8:54 PM, cocoa-dev-requ...@lists.apple.com wrote:
 
 Message: 3
 Date: Tue, 05 May 2015 17:31:23 -0400
 From: davel...@mac.com
 To: CocoaDev cocoa-dev@lists.apple.com
 Subject: Core Data sync between iOS and Mac apps
 
 I'm looking into options for building an iOS and Mac app that can sync/share 
 Core Data between them. I'm well aware of the issues with Core Data iCloud 
 syncing in iOS 5 and 6 and that it is supposedly better so I'm willing to 
 try it. The apps can have deployment targets of iOS 8 and greater and OS X 
 10.10

Re: Core Data sync between iOS and Mac apps

[Alex Kac]

I would try CloudKit. Its super simple and far simpler than using Dropbox.
Plus using Dropbox you end up with lots of issues going forward that you
don't want to mess with. Different database versions, data that is not
written to disk when you make the copy due to disk caches, and a lot more.

CloudKit is Apple's solution for sync between Apple devices. CoreData sync
over iCloud was never going to work well. I loved the idea, but as everyone
knows its implementation wasn't really foolproof. Many of us realized that
the better solution is a cloud sync that we designed ourselves. Apple
providing CloudKit solves that for Apple-only users.



On Sun, May 10, 2015 at 7:16 AM, davel...@mac.com wrote:


 Thanks MIchael. That's what I was afraid of (i.e., that Apple doesn't make
 this straightforward). I first looked at BSManagedDocument 2-3 years ago
 but never got around to trying it for my original app as I kept hoping
 Apple would have an official solution to this problem.

 Also thanks to Jens Alfke for his reply about Couchbase Lite (
 http://www.couchbase.com/nosql-databases/couchbase-mobile). I may look
 into it but after skimming the site, I couldn't tell exactly what I would
 need (i.e., would I need to setup my own server or use a server that your
 company provides, etc.). I doubt my app would generate enough income to
 even cover the server costs. My apps are for teachers and I write them
 because I want to use them myself but they don't generate much money given
 the fairly narrow target audience and that many schools provide systems the
 teacher has to use for the tasks (i.e., my existing iOS apps, Attendance
 and Attendance2 are for taking attendance in class and generating reports,
 etc.). Jens, I may send you an email off-list with a few more questions
 (that you can ignore if you want).

 I may just end up using Dropbox without sync (i.e., have the user send the
 data to Dropbox from the iOS app) when they want to use it on the Mac and
 import the data from Dropbox into iOS after the data has been changed on
 the Mac. It's not elegant but it's better than risking data corruption via
 an automatic sync that isn't reliable. Perhaps with some warnings about
 which data is newer by looking at modification dates from the file
 metadata, it could be usable. The app is mainly intended to be used on iOS
 but I want to use the Mac for one or two features that would not work well
 on iOS.

 Dave


  On May 7, 2015, at 10:57 AM, Michael Swan michaels...@mac.com wrote:
 
  Dave,
  Unfortunately on the OS X side with iCloud, Core Data, and documents it
 is pretty much a pick any two situation. The iOS side can be done but there
 are some gotchas not really covered in the documentation. I've actually
 just started work on my own custom subclasses of UIManagedDocument and
 NSDocument (NSPersistentDocument is less than useless if you want to share
 with iOS). My current plan is to use Apple's code as much as possible
 without adding extra stores like Ensembles does. If you're interested we
 could talk about a collaboration to build an open sourced set of classes to
 handle this area. (I plan to include a file browser for iOS as well since
 nothing currently exists.)
 
  On iOS you set two keys in the options dictionary to tell the system
 where to keep the change logs and what the name should be. The name is
 typically a UUID and the location is generally some version of ChangeLogs
 at the root level of the ubiquity container. The catch is that your can't
 set those options in configurePersistentStoreCoordinator… and have it come
 out right. You have to init the document then set the
 persistentStoreOptions property to a dictionary with those keys in order
 for the file package to get the right structure. You also need to create
 the document locally first and then move it to the ubiquity container.
 
  On OS X NSPersistentDocument can only make flat files, not packages like
 UIManagedDocument (I've filed a bug about there being no counterpart to
 UIManagedDocument for OS X, been open for over a year now…).
 BSManagedDocument will create a file package that looks like a locally
 stored UIManagedDocument but it doesn't have the logic for dealing with
 files in iCloud (my current plan is to build a subclass of
 BSManagedDocument with the extra logic in place).
 
  Apple's answer to me when I have asked about this in he past is that it
 is possible to sync Core Data documents through iCloud but you have to do
 all the heavy lifting (I have no idea if that will change in June, but I
 doubt it).
 
  As far as entitlements go you just need the document option enabled and
 to ensure that both apps use the same container.
 
  On the Mac the documents should show up in the normal open sheet just
 like they do for TextEdit and Preview documents that are in the cloud.
 
  These guides are a good starting point:
  Document Based App Programming Guide for Mac
  Document Based App Programming Guide for iOS
  iCloud Design

Re: Core Data sync between iOS and Mac apps

[Jens Alfke]

 On May 10, 2015, at 6:16 AM, davel...@mac.com wrote:
 
 Also thanks to Jens Alfke for his reply about Couchbase Lite 
 (http://www.couchbase.com/nosql-databases/couchbase-mobile). I may look into 
 it but after skimming the site, I couldn't tell exactly what I would need 
 (i.e., would I need to setup my own server or use a server that your company 
 provides, etc.).

Couchbase doesn’t (yet?) offer a hosted server, although it’s pretty easy to 
set one up in a generic hosting environment like AWS or Heroku. Also, the 
replication protocol is compatible with that used by Cloudant’s hosting service.

One thing I’d like would be a lightweight turnkey replication server you could 
easily run on a Mac or PC. I think that would be appealing for many users, 
partly because they’d have control over where their data is stored. We’ve done 
this as a proof-of-concept (it even runs on a Raspberry Pi!) but so far it has 
too many moving parts for it to be something an end user can easily set up.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data sync between iOS and Mac apps

[Sean McBride]

On Thu, 7 May 2015 10:57:05 -0400, Michael Swan said:

On OS X NSPersistentDocument can only make flat files, not packages like
UIManagedDocument (I've filed a bug about there being no counterpart to
UIManagedDocument for OS X, been open for over a year now…).

Only a year?  Mine's been open for 3 years now.  Duped to rdar://9447453 
which is still open too.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data sync between iOS and Mac apps

[Michael Swan]

Dave,
Unfortunately on the OS X side with iCloud, Core Data, and documents it is 
pretty much a pick any two situation. The iOS side can be done but there are 
some gotchas not really covered in the documentation. I've actually just 
started work on my own custom subclasses of UIManagedDocument and NSDocument 
(NSPersistentDocument is less than useless if you want to share with iOS). My 
current plan is to use Apple's code as much as possible without adding extra 
stores like Ensembles does. If you're interested we could talk about a 
collaboration to build an open sourced set of classes to handle this area. (I 
plan to include a file browser for iOS as well since nothing currently exists.)

On iOS you set two keys in the options dictionary to tell the system where to 
keep the change logs and what the name should be. The name is typically a UUID 
and the location is generally some version of ChangeLogs at the root level of 
the ubiquity container. The catch is that your can't set those options in 
configurePersistentStoreCoordinator… and have it come out right. You have to 
init the document then set the persistentStoreOptions property to a dictionary 
with those keys in order for the file package to get the right structure. You 
also need to create the document locally first and then move it to the ubiquity 
container.

On OS X NSPersistentDocument can only make flat files, not packages like 
UIManagedDocument (I've filed a bug about there being no counterpart to 
UIManagedDocument for OS X, been open for over a year now…). BSManagedDocument 
will create a file package that looks like a locally stored UIManagedDocument 
but it doesn't have the logic for dealing with files in iCloud (my current plan 
is to build a subclass of BSManagedDocument with the extra logic in place).

Apple's answer to me when I have asked about this in he past is that it is 
possible to sync Core Data documents through iCloud but you have to do all the 
heavy lifting (I have no idea if that will change in June, but I doubt it).

As far as entitlements go you just need the document option enabled and to 
ensure that both apps use the same container.

On the Mac the documents should show up in the normal open sheet just like they 
do for TextEdit and Preview documents that are in the cloud.

These guides are a good starting point:
Document Based App Programming Guide for Mac
Document Based App Programming Guide for iOS 
iCloud Design Guide
iCloud Programming Guide For Core Data

Thanks,
Mike Swan
ETCP Certified Entertainment Electrician
347-451-5418
theMikeSwan.com

 On May 5, 2015, at 8:54 PM, cocoa-dev-requ...@lists.apple.com wrote:
 
 Message: 3
 Date: Tue, 05 May 2015 17:31:23 -0400
 From: davel...@mac.com
 To: CocoaDev cocoa-dev@lists.apple.com
 Subject: Core Data sync between iOS and Mac apps
 Message-ID: 7feb2ad4-ecec-4562-ae17-1cc1e1b73...@mac.com
 Content-Type: text/plain; charset=us-ascii
 
 
 I'm looking into options for building an iOS and Mac app that can sync/share 
 Core Data between them. I'm well aware of the issues with Core Data iCloud 
 syncing in iOS 5 and 6 and that it is supposedly better so I'm willing to try 
 it. The apps can have deployment targets of iOS 8 and greater and OS X 10.10. 
 I don't expect they'll be ready to release before iOS 9 and 10.11 (or 
 whatever it's called) are out. The apps will be document-based in that the 
 user can open different data files each which should sync separately.
 
 The most detail explanation I can find of iCloud Core Data syncing is WWDC 
 2013 session 207 (which apparently also applies to iOS 8) and the objc.io 
 issue: http://www.objc.io/issue-10/icloud-core-data.html
 
 I looked into Ensembles (http://www.ensembles.io) a bit last year and bought 
 a support package. I'm also aware of BSManagedDocument (but haven't tried 
 using it). And I've seen this 
 http://ossh.com.au/design-and-technology/software-development/ but I didn't 
 see any accompanying code.
 
 I'm comfortable with Objective-C, Swift, and Core Data locally, but not 
 syncing Core Data.
 
 Is there someone where that I should look for that describes the steps in 
 detail including setting the proper entitlements, etc. in Xcode 6?
 
 I assume now that the iOS synced data would show up in the iCloud Drive on 
 the Mac - correct - or am I missing something that it is only for iCloud 
 Documents, not Core Data sync? I don't quite understand how 
 URLForUbiquityContainer comes into play on the Mac if the files now appear 
 local on the Mac. After the user chooses File - Open would they navigate to 
 the iCloud Drive and select the file? If so, how does the code then use 
 URLForUbiquityContainer.
 
 Pointers to any documentation or tutorials or recommendations would be 
 appreciated.
 
 Thanks,
 Dave Reed

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators

Re: Core Data sync between iOS and Mac apps

[Jens Alfke]

 On May 5, 2015, at 2:31 PM, davel...@mac.com wrote:
 
 I'm looking into options for building an iOS and Mac app that can sync/share 
 Core Data between them. I'm well aware of the issues with Core Data iCloud 
 syncing in iOS 5 and 6 and that it is supposedly better so I'm willing to try 
 it. 

I wouldn't recommend it. The sync mechanism for Core Data is IMHO a terrible 
kludge, and you have zero visibility into the server-side storage nor any 
ability to diagnose server-side problems. I still see user complaints in 
reviews of apps that use iCloud sync (Ulysses is one recent example.)

On the other hand, I'm biased because I work on a competing sync solution, 
Couchbase Lite*. It's designed from the ground up to do sync, you can run your 
own server, it supports multi-user sharing, and it's all open source. It has 
its own Cocoa API, but you can also use it as a back-end for Core Data.

Another solution to look into is Parse**. It's apparently pretty fast and 
reliable, although as a hosted service you don't have control over the servers 
(and you have to trust Facebook to play nice with your data.)

Dropbox has a data-sync API, but they just announced that they're deprecating 
it and phasing it out.

—Jens

* http://www.couchbase.com/nosql-databases/couchbase-mobile 
http://www.couchbase.com/nosql-databases/couchbase-mobile
** http://parse.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data sync between iOS and Mac apps

[davelist]

I'm looking into options for building an iOS and Mac app that can sync/share 
Core Data between them. I'm well aware of the issues with Core Data iCloud 
syncing in iOS 5 and 6 and that it is supposedly better so I'm willing to try 
it. The apps can have deployment targets of iOS 8 and greater and OS X 10.10. I 
don't expect they'll be ready to release before iOS 9 and 10.11 (or whatever 
it's called) are out. The apps will be document-based in that the user can 
open different data files each which should sync separately.

The most detail explanation I can find of iCloud Core Data syncing is WWDC 2013 
session 207 (which apparently also applies to iOS 8) and the objc.io issue: 
http://www.objc.io/issue-10/icloud-core-data.html

I looked into Ensembles (http://www.ensembles.io) a bit last year and bought a 
support package. I'm also aware of BSManagedDocument (but haven't tried using 
it). And I've seen this 
http://ossh.com.au/design-and-technology/software-development/ but I didn't see 
any accompanying code.

I'm comfortable with Objective-C, Swift, and Core Data locally, but not syncing 
Core Data.

Is there someone where that I should look for that describes the steps in 
detail including setting the proper entitlements, etc. in Xcode 6?

I assume now that the iOS synced data would show up in the iCloud Drive on the 
Mac - correct - or am I missing something that it is only for iCloud Documents, 
not Core Data sync? I don't quite understand how URLForUbiquityContainer comes 
into play on the Mac if the files now appear local on the Mac. After the user 
chooses File - Open would they navigate to the iCloud Drive and select the 
file? If so, how does the code then use URLForUbiquityContainer.

Pointers to any documentation or tutorials or recommendations would be 
appreciated.

Thanks,
Dave Reed


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Model Editor without Core Data

[Jerry Krinock]

 On 2015 Mar 20, at 21:25, Roland King r...@rols.org wrote:
 
 I don’t see that Apple has been neglecting Core Data.

I hope you are correct.  I suppose they were preoccupied with Swift last year.  
I had a dream last night that we’ll soon get a new “metal” persistent store to 
replace SQLite, one which is fundamentally compatible with asynchronous, 
autosaving synced documents.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data Model Editor without Core Data

[Jerry Krinock]

I’m rewriting a large old C++ (PowerPlant!) project to Cocoa, and am thinking 
that I’m probably not going to use Core Data because of its uncertain future (I 
think Apple has been neglecting it lately, its incompatibility with newer ideas 
such as asynchronous saving, etc.), and the fact this app may not need 
undo/redo.  But I think I might use the Core Data Model Editor in Xcode anyhow 
because it is really nice, and even if I don’t use Core Data, the code 
generated by mogenerator could easily be grepped to subclass Realm or FMDB 
objects instead of NSManagedObject.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Model Editor without Core Data

[Roland King]

 On 20 Mar 2015, at 22:25, Jerry Krinock je...@ieee.org wrote:
 
 I’m rewriting a large old C++ (PowerPlant!) project to Cocoa, and am thinking 
 that I’m probably not going to use Core Data because of its uncertain future 
 (I think Apple has been neglecting it lately, its incompatibility with newer 
 ideas such as asynchronous saving, etc.), and the fact this app may not need 
 undo/redo.  But I think I might use the Core Data Model Editor in Xcode 
 anyhow because it is really nice, and even if I don’t use Core Data, the code 
 generated by mogenerator could easily be grepped to subclass Realm or FMDB 
 objects instead of NSManagedObject.


I don’t see that Apple has been neglecting Core Data. There’s been steady 
incremental improvements over the last couple of WWDCs, the nicest of which is 
proper drop-in support for iCloud with the two stores it manages automagically 
for you. The changes they made to MOCs a few years back which use GCD make 
async saving pretty easy and last year we also got batch updates and async 
fetching. 




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Delete empty Core Data entities from to-many relationship

[Jerry Krinock]

 On 2015 Feb 13, at 11:27, Steve Mills sjmi...@mac.com wrote:
 
 Is there a better strategy for deleting empty container entities? At first I 
 tried setting the Asset's folder relationship to Cascade, but that threw up 
 all over.

Apparently the “count is never 1” because Core Data does not delete your Folder 
until the end of the run loop cycle.

A different approach would be maybe to register for 
NSObjectsChangedInManagingContextNotification.  Another alternative would be to 
use the Cascade Delete, and I’m not sure if you’ve done that because I didn’t 
scrutinize all the details in your post.  But that may not work as expected, as 
I learned in 2009…

http://lists.apple.com/archives/cocoa-dev/2009/Jun/msg01334.html

A shortcut I’ve learned is: Don't overthink Core Data.  If something doesn’t 
work as expected, accept it and try something different.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Delete empty Core Data entities from to-many relationship

[Steve Mills]

My model:

Folder:
attributes:
url
relationships:
Relationship: files, Destination: Asset, Inverse: folder, To 
Many, Deny
Relationship: keywords, Destination: Keyword, Inverse: assets, 
To Many, Nullify

Asset:
attributes:
stuff
relationships:
Relationship: folder, Destination: Folder, Inverse: files, To 
One, Nullify

Keyword:
attributes:
stuff
relationships:
Relationship: assets, Destination: Asset, Inverse: keywords, To 
Many, Nullify

When the last Asset that is a member of its Folder is deleted, I want to delete 
the now empty Folder. I added a prepareForDeletion override in Asset:

if(self.folder  self.folder.files.count == 1) {
Folder* fold = self.folder;

if([fold.files containsObject:self])
[self.managedObjectContext deleteObject:fold];
}

This works if I select one asset and delete it. But if I select multiple 
assets, it doesn't work. The count is never 1. It also spits out this:

2015-02-13 13:17:16.678 Image Chest[60293:9536015] Core Data: annotation: 
repairing missing delete propagation for to-many relationship files on object 
0x618b1400 (0x61830a60 
x-coredata:///Folder/t3FB1E228-B84C-46CC-BB8C-C3FB8E002318160) with bad fault 
0x618cea80 (0x60033e20 
x-coredata:///Asset/t3FB1E228-B84C-46CC-BB8C-C3FB8E002318163)
2015-02-13 13:17:16.678 Image Chest[60293:9536015] Core Data: annotation: 
repairing missing delete propagation for to-many relationship assets on object 
0x618a7620 (0x60420c40 
x-coredata:///Keyword/t3FB1E228-B84C-46CC-BB8C-C3FB8E002318161) with bad 
fault 0x618c57f0 (0x6003abc0 
x-coredata:///Asset/t3FB1E228-B84C-46CC-BB8C-C3FB8E002318162)
2015-02-13 13:17:16.678 Image Chest[60293:9536015] Core Data: annotation: 
repairing missing delete propagation for to-many relationship assets on object 
0x618a7620 (0x60420c40 
x-coredata:///Keyword/t3FB1E228-B84C-46CC-BB8C-C3FB8E002318161) with bad 
fault 0x618cea80 (0x60033e20 
x-coredata:///Asset/t3FB1E228-B84C-46CC-BB8C-C3FB8E002318163)


Is there a better strategy for deleting empty container entities? At first I 
tried setting the Asset's folder relationship to Cascade, but that threw up all 
over.

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data To-Many Relationship KVO

[Richard Charles]

I have a Core Data in-memory store. There is a managed object which uses KVO on 
a to-many relationship property of itself.

When an object at the other end of the relationship is deleted using 
[managedObjectContext deleteObject:object] the KVO change notification is not 
sent right away.

What triggers or will trigger the KVO change notification?

Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data To-Many Relationship KVO

[Roland King]

 On 12 Feb 2015, at 07:27, Richard Charles rcharles...@gmail.com wrote:
 
 I have a Core Data in-memory store. There is a managed object which uses KVO 
 on a to-many relationship property of itself.
 
 When an object at the other end of the relationship is deleted using 
 [managedObjectContext deleteObject:object] the KVO change notification is not 
 sent right away.
 
 What triggers or will trigger the KVO change notification?
 
 Richard Charles
 


committing the core data changes removes them from all the relationships and 
fires KVO changes. see propagatesDeletesAtEndOfEvent: and commitPendingChanges. 
In AppKit usually deletes are propagated once around the event loop, in other 
places they won’t propagate until there’s a save or commitPendingChanges: is 
called. 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data To-Many Relationship KVO

[Richard Charles]

 On Feb 11, 2015, at 4:51 PM, Roland King r...@rols.org wrote:
 
 committing the core data changes removes them from all the relationships and 
 fires KVO changes. see propagatesDeletesAtEndOfEvent: and 
 commitPendingChanges. In AppKit usually deletes are propagated once around 
 the event loop, in other places they won’t propagate until there’s a save or 
 commitPendingChanges: is called.


What “event” does propagatesDeletesAtEndOfEvent refer to? An event loop, some 
type of Core Data event? The documentation as I read it is unclear.

Also commitPendingChanges: does not appear to be in any method of the Cocoa 
frameworks.

Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data To-Many Relationship KVO

[Roland King]

 On 12 Feb 2015, at 08:27, Richard Charles rcharles...@gmail.com wrote:
 
 
 On Feb 11, 2015, at 4:51 PM, Roland King r...@rols.org wrote:
 
 committing the core data changes removes them from all the relationships and 
 fires KVO changes. see propagatesDeletesAtEndOfEvent: and 
 commitPendingChanges. In AppKit usually deletes are propagated once around 
 the event loop, in other places they won’t propagate until there’s a save or 
 commitPendingChanges: is called.
 
 
 What “event” does propagatesDeletesAtEndOfEvent refer to? An event loop, some 
 type of Core Data event? The documentation as I read it is unclear.

No idea - why don’t you put a breakpoint in your KVO handler and see where it’s 
being called from, my guess would be the end of the event loop. If you want it 
earlier try calling the method to process pending changes, or remove it from 
the relationship yourself as well as deleting it. 

 
 Also commitPendingChanges: does not appear to be in any method of the Cocoa 
 frameworks.

processPendingChanges:, it’s on NSManagedObjectContext

 
 Richard Charles
 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data To-Many Relationship KVO

[Richard Charles]

 On Feb 11, 2015, at 5:36 PM, Roland King r...@rols.org wrote:
 
 processPendingChanges:, it’s on NSManagedObjectContext

That’s what I was looking for.

Thanks for your help.

Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Show count of Core Data to-many relationship in NSTableView cell with bindings?

[Steve Mills]

On Feb 6, 2015, at 01:56:24, Quincey Morris 
quinceymor...@rivergatesoftware.com wrote:

 You can’t bind *through* an array or set collection class. However, you can 
 use these:
 
   
 https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/CollectionOperators.html
 

On Feb 6, 2015, at 02:03:34, Ken Thomases k...@codeweavers.com wrote:

 You can't use KVO or bindings through arrays or sets, even to their immediate 
 properties.
 
 For KVC, if you were to attempt to do [theTableCellView 
 valueForKeyPath:@objectValue.images.count], that would attempt to get the 
 count property of each _element_ of objectValue.images and return a set 
 containing all of those counts (wrapped in NSNumbers).  In theory, if KVO 
 through sets worked, then observing the key path objectValue.images.count 
 would not notify you when the count of objectValue.images changed.  It would 
 notify you when the set returned by [theTableCellView 
 valueForKeyPath:@objectValue.images.count] changed (or might have changed). 
  That's not what you want, anyway.
 
 However, there are collection operators 
 https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/CollectionOperators.html,
  including @count.  You can bind to that with model key path 
 objectValue.images.@count.

W doggies! Just when I was about to go to bed, you guys come through 
with the goods and make my night. :) Thanks so much. I need to read the KVC and 
KVO articles again.

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Show count of Core Data to-many relationship in NSTableView cell with bindings?

[Ken Thomases]

On Feb 6, 2015, at 1:43 AM, Steve Mills sjmi...@mac.com wrote:

 I have a Core Data entity called Keyword that has a to-many relationship to 
 another entity called Image. In a table that displays these Keywords, I want 
 one column to show the number of Images that use that particular Keyword. I 
 tried setting the Value binding for the Table View Cell to bind to the Table 
 Cell View with model key path of objectValue.images.count. That doesn't work 
 - throws an exception:
 
 [_NSFaultingMutableSet 0x620246e0 
 addObserver:forKeyPath:options:context:] is not supported. Key path: count
 
 Is it not possible to bind to an entity's relationship properties? The 
 Keyword class has a property named assets of class NSSet, so it seems like 
 the binding should be able to access it just like the attribute properties.

You can't use KVO or bindings through arrays or sets, even to their immediate 
properties.

For KVC, if you were to attempt to do [theTableCellView 
valueForKeyPath:@objectValue.images.count], that would attempt to get the 
count property of each _element_ of objectValue.images and return a set 
containing all of those counts (wrapped in NSNumbers).  In theory, if KVO 
through sets worked, then observing the key path objectValue.images.count would 
not notify you when the count of objectValue.images changed.  It would notify 
you when the set returned by [theTableCellView 
valueForKeyPath:@objectValue.images.count] changed (or might have changed).  
That's not what you want, anyway.

However, there are collection operators 
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/CollectionOperators.html,
 including @count.  You can bind to that with model key path 
objectValue.images.@count.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Show count of Core Data to-many relationship in NSTableView cell with bindings?

[Steve Mills]

I have a Core Data entity called Keyword that has a to-many relationship to 
another entity called Image. In a table that displays these Keywords, I want 
one column to show the number of Images that use that particular Keyword. I 
tried setting the Value binding for the Table View Cell to bind to the Table 
Cell View with model key path of objectValue.images.count. That doesn't work - 
throws an exception:

[_NSFaultingMutableSet 0x620246e0 
addObserver:forKeyPath:options:context:] is not supported. Key path: count

Is it not possible to bind to an entity's relationship properties? The Keyword 
class has a property named assets of class NSSet, so it seems like the binding 
should be able to access it just like the attribute properties.

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Show count of Core Data to-many relationship in NSTableView cell with bindings?

[Quincey Morris]

On Feb 5, 2015, at 23:43 , Steve Mills sjmi...@mac.com wrote:
 
 [_NSFaultingMutableSet 0x620246e0 
 addObserver:forKeyPath:options:context:] is not supported. Key path: count
 
 Is it not possible to bind to an entity's relationship properties?

You can’t bind *through* an array or set collection class. However, you can use 
these:


https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/CollectionOperators.html
 
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/CollectionOperators.html



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Dave Fernandes]

NSPersistentDocument is not designed to work with “modern” features like 
private queue MOCs. So I expect you are going to be playing whack-a-mole if you 
go this route. I just switched to Mike Abdullah’s BSManagedDocument. It is like 
UIManagedDocument, but for OS X. If you don’t have any customers on this app 
yet, BSManagedDocument is pretty much a drop-in replacement for 
NSPersistentDocument. If you have customers, you will need to migrate them, but 
that is straightforward and probably much lower risk than trying to get 
NSPersistentDocument to support something it is not designed for.

 On Feb 3, 2015, at 1:48 AM, Steve Mills sjmi...@mac.com wrote:
 
 On Feb 2, 2015, at 17:36:22, Roland King r...@rols.org wrote:
 
 get the NSManagedObjectContext the document creates for you with [ super 
 managedObjectContext ], get the store coordinator with [ 
 managedObjectContext persistentStoreCoordinator ], create your own MOCs on 
 that store, hold on to the MOC you have just created, ignore the one super 
 created (or perhaps you can nil it, not sure) and then return it. 
 
 That sounds interesting. I've tried it, and it causes my managedObjectContext 
 override to be called twice during document creation. The 2nd call is caused 
 by my managedObjectContext override calling [super managedObjectContext], and 
 super tries to set up the undo manager for its managedObjectContext. I don't 
 know if this is harmless or OK.
 
 So since no exceptions are thrown during the creating of my own MOCs, I go 
 ahead and add objects to a temp private MOC whose parent is my 
 managedObjectContext. That works and my table view is populated after it 
 completes. But when I try to save at the end of my concurrent object-adding 
 block, it throws:
 
 CoreData: error: Illegal attempt to save to a file that was never opened. 
 This NSPersistentStoreCoordinator has no persistent stores (unknown).  It 
 cannot perform a save operation.. No last error recorded.
 An uncaught exception was raised
 This NSPersistentStoreCoordinator has no persistent stores (unknown).  It 
 cannot perform a save operation.
 (
   0   CoreFoundation  0x7fff8569b66c 
 __exceptionPreprocess + 172
   1   libobjc.A.dylib 0x7fff87dfd76e 
 objc_exception_throw + 43
   2   CoreData0x7fff898b7eb3 
 -[NSPersistentStoreCoordinator 
 _coordinator_you_never_successfully_opened_the_database_so_saving_back_to_it_is_kinda_hard:]
  + 51
   3   CoreData0x7fff898b810d 
 -[NSPersistentStoreCoordinator _introspectLastErrorAndThrow] + 77
   4   CoreData0x7fff898b8236 
 __65-[NSPersistentStoreCoordinator 
 executeRequest:withContext:error:]_block_invoke + 166
   5   CoreData0x7fff898c331b 
 gutsOfBlockToNSPersistentStoreCoordinatorPerform + 171
   6   libdispatch.dylib   0x000100025d43 
 _dispatch_client_callout + 8
   7   libdispatch.dylib   0x0001000270b1 
 _dispatch_barrier_sync_f_invoke + 348
   8   CoreData0x7fff898b2312 _perform + 
 194
   9   CoreData0x7fff89804395 
 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 533
   10  CoreData0x7fff898043c4 
 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 580
   11  CoreData0x7fff8982eb3b 
 -[NSManagedObjectContext save:] + 1291
   12  Image Chest 0x00012291 -[Document 
 unsafeSaveContext:] + 113
   13  Image Chest 0x0001213a 
 __24-[Document saveContext:]_block_invoke + 42
   14  CoreData0x7fff8984a246 
 developerSubmittedBlockToNSManagedObjectContextPerform + 182
   15  libdispatch.dylib   0x000100025d43 
 _dispatch_client_callout + 8
   16  libdispatch.dylib   0x000100029fb3 
 _dispatch_queue_drain + 1804
   17  libdispatch.dylib   0x00010002bfc0 
 _dispatch_queue_invoke + 223
   18  libdispatch.dylib   0x000100028f5e 
 _dispatch_root_queue_drain + 666
   19  libdispatch.dylib   0x00010003acd0 
 _dispatch_worker_thread3 + 106
   20  libsystem_pthread.dylib 0x7fff92a82637 
 _pthread_wqthread + 729
   21  libsystem_pthread.dylib 0x7fff92a8040d 
 start_wqthread + 13
 )
 
 The save model is based on Jerry's YaBT sample mentioned earlier in the 
 thread, which has a rootContext (NSPrivateQueueConcurrencyType), mainContext 
 (NSMainQueueConcurrencyType), and tempContext (NSPrivateQueueConcurrencyType) 
 in a chain of children. I'm guessing it's because the document has not been 
 saved to disk yet, whereas the YaBT sets up a file for the 

Re: Core Data concurrency during import of folder contents

[Steve Mills]

On Feb 3, 2015, at 06:51:35, Dave Fernandes dave.fernan...@utoronto.ca wrote:
 
 NSPersistentDocument is not designed to work with “modern” features like 
 private queue MOCs. So I expect you are going to be playing whack-a-mole if 
 you go this route. I just switched to Mike Abdullah’s BSManagedDocument. It 
 is like UIManagedDocument, but for OS X. If you don’t have any customers on 
 this app yet, BSManagedDocument is pretty much a drop-in replacement for 
 NSPersistentDocument. If you have customers, you will need to migrate them, 
 but that is straightforward and probably much lower risk than trying to get 
 NSPersistentDocument to support something it is not designed for.

That's interesting. Too bad it always saves as a package, but it gives me 
something to work with. This is a new app. Actually, a new Cocoa version of an 
old app, so it has no users really. The old version saved a package, but I was 
hoping to get away from that with this version, but I guess as long as it's 
already saving a package…

I was able to base my document class on BSManagedDocument, created a temp 
private context for concurrently adding large amounts of objects to it, and it 
did not block the main thread. Thanks! Now I can get on with actually doing the 
rest of the app!

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Jerry Krinock]

 On 2015 Feb 03, at 08:02, Steve Mills sjmi...@mac.com wrote:
 
 On Feb 3, 2015, at 06:51:35, Dave Fernandes dave.fernan...@utoronto.ca 
 wrote:
 
 Mike Abdullah’s BSManagedDocument.
 
 Too bad it always saves as a package

Actually, that’s an advantage, because flat files do not play well with the new 
Write Ahead Lookup (WAL) journal mode of SQLite.  Definitely use 
BSManagedDocument for new apps.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Steve Mills]

On Jan 31, 2015, at 12:00:03, Jerry Krinock je...@ieee.org wrote:
 
 
 
 I liked this one [1] by Aaron Douglas (all in Swift) when I was needed to do 
 a presentation on Core Data last September.  And then, in a rage of NIH [2], 
 I wrote my own [3] instead, in Objective-C.  The one Swift alternative file 
 in there is still untested :))
 
 Finally, always check Ray Wenderlich’s site [4] when you want sample code.
 
 1.  
 https://github.com/astralbodies/CoreDataConcurrencyDemo/tree/master/CoreDataConcurrencyDemo
 2.  http://en.wikipedia.org/wiki/Not_invented_here
 3.  https://github.com/jerrykrinock/YaBT-Yet-another-Bug-Tracker
 4.  http://www.raywenderlich.com

I'm having a hard time figuring out how to make this work with an 
NSPersistentDocument. All the examples I've looked at are for iOS, so they all 
set up their own complete Core Data stack. What I'm trying to do - based on 
these examples - is to override the document's managedObjectContext method, 
which is where I'll create the NSMainQueueConcurrencyType MOC, and set its 
parent to the NSPrivateQueueConcurrencyType root MOC. But in order to create 
the root MOC, I need to get at the NSPersistentDocument's 
NSPersistentStoreCoordinator, but there is no method or property to get at 
that. Do I just create my own NSPersistentStoreCoordinator instead, like the 
iOS examples do?

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Roland King]

 On 3 Feb 2015, at 04:25, Steve Mills sjmi...@mac.com wrote:
 
 On Jan 31, 2015, at 12:00:03, Jerry Krinock je...@ieee.org wrote:
 
 
 
 I liked this one [1] by Aaron Douglas (all in Swift) when I was needed to do 
 a presentation on Core Data last September.  And then, in a rage of NIH [2], 
 I wrote my own [3] instead, in Objective-C.  The one Swift alternative file 
 in there is still untested :))
 
 Finally, always check Ray Wenderlich’s site [4] when you want sample code.
 
 1.  
 https://github.com/astralbodies/CoreDataConcurrencyDemo/tree/master/CoreDataConcurrencyDemo
 2.  http://en.wikipedia.org/wiki/Not_invented_here
 3.  https://github.com/jerrykrinock/YaBT-Yet-another-Bug-Tracker
 4.  http://www.raywenderlich.com
 
 I'm having a hard time figuring out how to make this work with an 
 NSPersistentDocument. All the examples I've looked at are for iOS, so they 
 all set up their own complete Core Data stack. What I'm trying to do - based 
 on these examples - is to override the document's managedObjectContext 
 method, which is where I'll create the NSMainQueueConcurrencyType MOC, and 
 set its parent to the NSPrivateQueueConcurrencyType root MOC. But in order 
 to create the root MOC, I need to get at the NSPersistentDocument's 
 NSPersistentStoreCoordinator, but there is no method or property to get at 
 that. Do I just create my own NSPersistentStoreCoordinator instead, like the 
 iOS examples do?
 
 --
 Steve Mills
 Drummer, Mac geek


get the NSManagedObjectContext the document creates for you with [ super 
managedObjectContext ], get the store coordinator with [ managedObjectContext 
persistentStoreCoordinator ], create your own MOCs on that store, hold on to 
the MOC you have just created, ignore the one super created (or perhaps you can 
nil it, not sure) and then return it. 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Steve Mills]

On Feb 2, 2015, at 17:36:22, Roland King r...@rols.org wrote:
 
 get the NSManagedObjectContext the document creates for you with [ super 
 managedObjectContext ], get the store coordinator with [ managedObjectContext 
 persistentStoreCoordinator ], create your own MOCs on that store, hold on to 
 the MOC you have just created, ignore the one super created (or perhaps you 
 can nil it, not sure) and then return it. 

That sounds interesting. I've tried it, and it causes my managedObjectContext 
override to be called twice during document creation. The 2nd call is caused by 
my managedObjectContext override calling [super managedObjectContext], and 
super tries to set up the undo manager for its managedObjectContext. I don't 
know if this is harmless or OK.

So since no exceptions are thrown during the creating of my own MOCs, I go 
ahead and add objects to a temp private MOC whose parent is my 
managedObjectContext. That works and my table view is populated after it 
completes. But when I try to save at the end of my concurrent object-adding 
block, it throws:

CoreData: error: Illegal attempt to save to a file that was never opened. This 
NSPersistentStoreCoordinator has no persistent stores (unknown).  It cannot 
perform a save operation.. No last error recorded.
An uncaught exception was raised
This NSPersistentStoreCoordinator has no persistent stores (unknown).  It 
cannot perform a save operation.
(
0   CoreFoundation  0x7fff8569b66c 
__exceptionPreprocess + 172
1   libobjc.A.dylib 0x7fff87dfd76e 
objc_exception_throw + 43
2   CoreData0x7fff898b7eb3 
-[NSPersistentStoreCoordinator 
_coordinator_you_never_successfully_opened_the_database_so_saving_back_to_it_is_kinda_hard:]
 + 51
3   CoreData0x7fff898b810d 
-[NSPersistentStoreCoordinator _introspectLastErrorAndThrow] + 77
4   CoreData0x7fff898b8236 
__65-[NSPersistentStoreCoordinator 
executeRequest:withContext:error:]_block_invoke + 166
5   CoreData0x7fff898c331b 
gutsOfBlockToNSPersistentStoreCoordinatorPerform + 171
6   libdispatch.dylib   0x000100025d43 
_dispatch_client_callout + 8
7   libdispatch.dylib   0x0001000270b1 
_dispatch_barrier_sync_f_invoke + 348
8   CoreData0x7fff898b2312 _perform + 
194
9   CoreData0x7fff89804395 
-[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 533
10  CoreData0x7fff898043c4 
-[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 580
11  CoreData0x7fff8982eb3b 
-[NSManagedObjectContext save:] + 1291
12  Image Chest 0x00012291 -[Document 
unsafeSaveContext:] + 113
13  Image Chest 0x0001213a 
__24-[Document saveContext:]_block_invoke + 42
14  CoreData0x7fff8984a246 
developerSubmittedBlockToNSManagedObjectContextPerform + 182
15  libdispatch.dylib   0x000100025d43 
_dispatch_client_callout + 8
16  libdispatch.dylib   0x000100029fb3 
_dispatch_queue_drain + 1804
17  libdispatch.dylib   0x00010002bfc0 
_dispatch_queue_invoke + 223
18  libdispatch.dylib   0x000100028f5e 
_dispatch_root_queue_drain + 666
19  libdispatch.dylib   0x00010003acd0 
_dispatch_worker_thread3 + 106
20  libsystem_pthread.dylib 0x7fff92a82637 
_pthread_wqthread + 729
21  libsystem_pthread.dylib 0x7fff92a8040d 
start_wqthread + 13
)

The save model is based on Jerry's YaBT sample mentioned earlier in the thread, 
which has a rootContext (NSPrivateQueueConcurrencyType), mainContext 
(NSMainQueueConcurrencyType), and tempContext (NSPrivateQueueConcurrencyType) 
in a chain of children. I'm guessing it's because the document has not been 
saved to disk yet, whereas the YaBT sets up a file for the persistent store 
when it creates it. Since the document sets up the store, I don't know what I'd 
do in this case.

Ugh. This needs to be more complicated and harder to comprehend.

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Jerry Krinock]

 On 2015 Jan 30, at 22:01, Steve Mills sjmi...@mac.com wrote:
 
 Isn't there just an example of a document-based app that implement concurrent 
 Core Data importing and all that jazz?

I liked this one [1] by Aaron Douglas (all in Swift) when I was needed to do a 
presentation on Core Data last September.  And then, in a rage of NIH [2], I 
wrote my own [3] instead, in Objective-C.  The one Swift alternative file in 
there is still untested :))

Finally, always check Ray Wenderlich’s site [4] when you want sample code.

1.  
https://github.com/astralbodies/CoreDataConcurrencyDemo/tree/master/CoreDataConcurrencyDemo
2.  http://en.wikipedia.org/wiki/Not_invented_here
3.  https://github.com/jerrykrinock/YaBT-Yet-another-Bug-Tracker
4.  http://www.raywenderlich.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data concurrency during import of folder contents

[Steve Mills]

I'm trying to learn Core Data. I have a working document model hooked up to a 
table view (OS X). I have an import method that uses FSDirectoryEnumerator to 
add an object for each file in the folder. Oky doke! But that blocks for a few 
seconds while it loops. So I'm trying to make it threaded. One example I saw 
uses GCD. It kinda seemed to work when I had a bunch of printfs in there so I 
could watch it progress, but when I took them out it just crashed at some 
point, and it still blocked any sort of user events.

Next I tried sticking the entire import operation into a block via 
NSOperationQueue's addOperationWithBlock:. That throws because some set was 
being changed by multiple threads. Then I tried the suggestion of using a 
private NSManagedObjectContext in the block. That got me somewhere, but of 
course the data didn't populate my table. I tried the 
NSManagedObjectContextDidSaveNotification trick, but I couldn't get that to 
work.

Reading the Concurrency with Core Data page online says the information is 
outdated. Where do I find current documentation? Or better yet, an actual 
example that actually works? My brain is about to explode, and nobody wants to 
clean that up.

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Terrence Geernaert]

I prefer the GCD method but there are a few details that cause people trouble 
when combining GCD with CoreData. 
1. A named GCD queue may guarantee serial processing but it does not guarantee 
that it will always use the same thread
2. NSManagedObjectContexts are not thread safe, and it’s not just a problem of 
you avoiding access from two threads at the same time. Only access the MOC from 
the thread on which it was created.
3 MOCs are light weight, so don’t worry about the premature optimization when 
creating and destroying them... unless it becomes an issue.

In other words a private MOC is not the complete answer. Inside your block you 
need to create a new MOC, save it once you’ve completed your long running data 
collection process and then destroy it at the end of the block.  You should 
have another MOC that you keep around, waiting on the main thread to be made 
aware of the save, so that you can handle the changes in your FRC.  This is not 
the whole story (you can use child MOCs for a little more sophistication) but 
this should you going in the right direction.  
__
Terrence


 On Jan. 30, 2015, at 9:20 AM, Steve Mills sjmi...@mac.com wrote:
 
 I'm trying to learn Core Data. I have a working document model hooked up to a 
 table view (OS X). I have an import method that uses FSDirectoryEnumerator to 
 add an object for each file in the folder. Oky doke! But that blocks for a 
 few seconds while it loops. So I'm trying to make it threaded. One example I 
 saw uses GCD. It kinda seemed to work when I had a bunch of printfs in there 
 so I could watch it progress, but when I took them out it just crashed at 
 some point, and it still blocked any sort of user events.
 
 Next I tried sticking the entire import operation into a block via 
 NSOperationQueue's addOperationWithBlock:. That throws because some set was 
 being changed by multiple threads. Then I tried the suggestion of using a 
 private NSManagedObjectContext in the block. That got me somewhere, but of 
 course the data didn't populate my table. I tried the 
 NSManagedObjectContextDidSaveNotification trick, but I couldn't get that to 
 work.
 
 Reading the Concurrency with Core Data page online says the information is 
 outdated. Where do I find current documentation? Or better yet, an actual 
 example that actually works? My brain is about to explode, and nobody wants 
 to clean that up.
 
 --
 Steve Mills
 Drummer, Mac geek
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/tgeernaert%40gmail.com
 
 This email sent to tgeerna...@gmail.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Roland King]

 On 31 Jan 2015, at 01:20, Steve Mills sjmi...@mac.com wrote:
 
 I'm trying to learn Core Data. I have a working document model hooked up to a 
 table view (OS X). I have an import method that uses FSDirectoryEnumerator to 
 add an object for each file in the folder. Oky doke! But that blocks for a 
 few seconds while it loops. So I'm trying to make it threaded. One example I 
 saw uses GCD. It kinda seemed to work when I had a bunch of printfs in there 
 so I could watch it progress, but when I took them out it just crashed at 
 some point, and it still blocked any sort of user events.
 
 Next I tried sticking the entire import operation into a block via 
 NSOperationQueue's addOperationWithBlock:. That throws because some set was 
 being changed by multiple threads. Then I tried the suggestion of using a 
 private NSManagedObjectContext in the block. That got me somewhere, but of 
 course the data didn't populate my table. I tried the 
 NSManagedObjectContextDidSaveNotification trick, but I couldn't get that to 
 work.
 
 Reading the Concurrency with Core Data page online says the information is 
 outdated. Where do I find current documentation? Or better yet, an actual 
 example that actually works? My brain is about to explode, and nobody wants 
 to clean that up.
 

Oh yes the documentation does say that doesn't it - that's a shame. My first 
recommendation right off the bat (and it's the same one I make often) is to go 
watch the core data videos from WWDC going back to about 2011 when I believe 
all the 'new' concurrency was introduced. It's a time-investment but there's 
loads of good stuff in there which I find helps immensely and you really can't 
find out any other way. (The 2014 video has a brief runthrough towards the 
start of the history of concurrency with Core Data, that's at least a start). 

At this point, NSThreadConfinementCurrencyType, the default since confinement 
types were introduced, is basically obsolete and there was a warning in the 
2014 WWDC video that it's going to go away. The concept of worrying about 
threads has really gone away with it. So you don't need your own operations 
queues, you should use an MOC which is NSPrivateQueueConcurrencyType and .. 
this is important .. send all requests to it on with performBlock: or 
performBlockAndWait: method. This will happily use GCD under the hood and 
serialize on the queue. Your UI should use an NSMainQueueConcurrencyType 
usually, because then you're always on the right queue when updating your UI. 

Two ways to get the results back into the MOC which is backing your table, one 
which you probably currently created as a default MOC with 
NSConfinementCurrencyType (the default) but which you should possibly think 
about changing to the main queue type. Then you have a couple of options, you 
can have an entirely separate MOC in which you do your import, or you can make 
a child MOC of the main one, of type NSPrivateQueueConcurrencyType, and do the 
import then, then 'save' it which will push the changes into the parent. I've 
done both, I prefer the separate MOC approach for bulk data import and use the 
child context paradigm mostly for discardable edits, for which it's really 
well-suited. 

NSManagedObjectContextDidSaveNotification is regrettably not a trick, it's how 
different MOCs talk to each other. So you need to get that to work. I think 
when I started with Core Data I tried hard to avoid it because I don't 'do' 
notifications, and then I gave up trying to avoid it, figured it out once and 
used it. What about it couldn't you get to work? When a context saves it sends 
that notification (plus another one before and one after to tell you things 
have changed and that it was saved) to anyone who cares to listen, it's that 
simple (as long as you called save). Core Data itself is very good at updating 
your local MOC with the results of such a notification, you really just need to 
get the notification and hand it to your MOC to figure out. If you want to be 
clever about it and inspect the notification to figure out exactly what objects 
changed and how to update your UI minimally, you can do that, a first dumb 
approach is get notification, call core data method to update local MOC, call 
reloadData on your table. Not pretty but a place to start. 

So I'd say probably go back to the notification and figure out what it was you 
were having problems with there, if you want a background import, you're going 
to need to get to the bottom of that. 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data concurrency during import of folder contents

[Steve Mills]

Isn't there just an example of a document-based app that implement concurrent 
Core Data importing and all that jazz? I see tons and tons of little scraps of 
info and examples (which end up not working with my app as it is because it was 
written based on Apple's outdated documentation), but not the whole picture.

--
Steve Mills
Drummer, Mac geek


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

XC Unit tests issues with Core Data

[Rick Mann]

I'm trying to set up a unit test to exercise parts of my iOS app's code, which 
includes Core Data code. The test case does not run with the app as Test Host. 
My test case copies the test data to a temporary directory, loads the Core Data 
stack using the test cases' class bundle and pointing to the sqlite file in the 
temporary test data directory, and begins work. The work is asynchronous, so 
the test case sets up an expectation and waits.

The code then does a fetch request to get a few Job entities, loops over them 
and processes each in turn. The problems is, sometimes, the reference to the 
Job is nil when it's finally worked on. It seems that the Jobs are being 
deallocated, despite being held. Here's the code:

https://pastee.org/5j7hx

What bothers me is that the deletionQueue block has a reference to all the jobs 
in its local NSArray. But those job objects are being deallocated before it 
finishes. Any ideas? Thanks!

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Changes to Core Data in iOS 8

[Rick Mann]

In iOS 7, my app works fine. In iOS 8, deleting an entity eventually works, but 
whereas in iOS 7 my UI would update and show the change, the change doesn't 
seem to have taken hold by this time in iOS 8.

Basically, when the user deletes an entity, I delete it from the MOC (main 
thread), then mark my custom view as needing display. Its -drawRect: is called, 
but when it asks the owning entity for the set of related entities it draws, 
that set comes back with the deleted items still present (although they return 
true for -isDeleted).

When a later event causes the custom view to refresh again, the entity 
representations finally go away.

Has something changed in delete propagation between iOS 7 and 8?

TIA,

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Changes to Core Data in iOS 8

[Kyle Sluder]

On Sep 23, 2014, at 4:24 PM, Rick Mann rm...@latencyzero.com wrote:
 
 In iOS 7, my app works fine. In iOS 8, deleting an entity eventually works, 
 but whereas in iOS 7 my UI would update and show the change, the change 
 doesn't seem to have taken hold by this time in iOS 8.
 
 Basically, when the user deletes an entity, I delete it from the MOC (main 
 thread), then mark my custom view as needing display. Its -drawRect: is 
 called, but when it asks the owning entity for the set of related entities it 
 draws, that set comes back with the deleted items still present (although 
 they return true for -isDeleted).
 
 When a later event causes the custom view to refresh again, the entity 
 representations finally go away.
 
 Has something changed in delete propagation between iOS 7 and 8?

Have you checked the value of your MOC’s propagatesDeletesAtEndOfEvent property 
on iOS 7 and iOS 8?

But more fundamentally, why aren’t you listening for 
NSManagedObjectContextObjectsDidChangeNotification to trigger your UI updates?

--Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cleaning up after manual Core Data migration

[Jerry Krinock]

On 2014 Sep 11, at 15:38, Rick Mann rm...@latencyzero.com wrote:

 The problem is, I now have to specify the destination URL explicitly, and I'm 
 not able to give it the source URL. So, I create a new sqlite data file, and 
 that's fine. But the old sqlite DB actually has three files (DB.sqlite, 
 DB.sqlite-shm, DB.sqlite-wal),

These will explain to you what those pesky -shm and -wal files are:

https://developer.apple.com/library/prerelease/ios/qa/qa1809/_index.html
http://www.sqlite.org/wal.html

However reverting to legacy rollback journaling with heavyweight migration 
needs a workaround due to Apple Bug 16038419:

http://openradar.appspot.com/radar?id=5784482221129728

and it may be too late for that anyhow if you have data already in the field.

 so when I swap the new and old files after the migration completes, there's 
 still leftover sqlite metadata in the form of these additional files,

Those -shm and -wal files may contain actual data, not just metadata.

 and SQLite thinks the newly migrated DB is corrupt.

without the -shm and -wal files, it probably *is* corrupt.

 I can, of course, just delete these additional files,

I don’t think so.

 but it's an implementation detail I'd rather not put in my code. Am I 
 overlooking some more elegant way to update the on-disk files?

According to http://www.sqlite.org/wal.html, A checkpoint operation takes 
content from the WAL file and transfers it back into the original database 
file”.  You can do this with sqlite3_wal_checkpoint_v2().  But digging in the 
database with sqlite behind Core Data’s back is not elegant.  You could also 
copy all three files.  Pick whichever way you deem to be least un-elegant :)

I’ve often wondered why SQLite author D. Richard Hipp found it necessary to put 
the write-ahead log and shared memory in separate files.  He must have realized 
how much pain it was going to cause.  But he’s a very smart guy so I presume 
there is a good reason for it.

If you need to discuss this further, tell us if the app is iOS or OS X, and 
also is this database a document (UIManagedDocument or NSPersistentDocument)?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Cleaning up after manual Core Data migration

[Rick Mann]

Up until now I've performed a complex Core Data migration using Mapping Models 
and custom migration policy subclasses, but initiated automatically upon 
creating the persistent store coordinator, and it works fine. But 
unfortunately, it's taking too long, so I have to initiate it manually on a 
background thread, with an instance of a migration manager I create, and then 
display some progress.

The problem is, I now have to specify the destination URL explicitly, and I'm 
not able to give it the source URL. So, I create a new sqlite data file, and 
that's fine. But the old sqlite DB actually has three files (DB.sqlite, 
DB.sqlite-shm, DB.sqlite-wal), so when I swap the new and old files after the 
migration completes, there's still leftover sqlite metadata in the form of 
these additional files, and SQLite thinks the newly migrated DB is corrupt.

I can, of course, just delete these additional files, but it's an 
implementation detail I'd rather not put in my code. Am I overlooking some more 
elegant way to update the on-disk files?

TIA,

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Generating Core Data classes in Swift

[Jim Geist]

Say my app is called MyGreatApp, and I have a Core Data entity named Entity. 
Per instructions, I namespace the class associated with the entity and call it 
MyGreatApp.Entity. When I use Create NSManagedObject Subclasses and tell it to 
generate Swift files, I get a class called MyGreatApp that contains the 
attributes from Entity.

Is this known broken? Workaround other than hand-tweaking the class? I have the 
current Xcode beta.

Thanks!



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Generating Core Data classes in Swift

[Jerry Krinock]

On 2014 Sep 05, at 20:22, Jim Geist velocity...@rodentia.net wrote:

 Workaround other than hand-tweaking the class?

You could use mogenerator instead of Xcode to generate your Core Data classes.  
Although I’ve not tried it yet, supposedly  mogenerator now has a —-swift 
option.

https://github.com/rentzsch/mogenerator

The latest pre-built binary download, mogenerator 1.27, does not support Swift. 
 You will therefore need to clone and build mogenerator from source.  But I 
just did that the other day and it worked perfectly.

In case you’re not familiar with mogenerator, here is a good sales pitch…

https://github.com/rentzsch/mogenerator


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Generating Core Data classes in Swift

[Jerry Krinock]

Correct link to mogenerator good sales pitch…

http://raptureinvenice.com/getting-started-with-mogenerator/



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com