Re: Opinion: Core Data or roll my own?
Re: Opinion: Core Data or roll my own?
- Subject: Re: Opinion: Core Data or roll my own?
- From: edward taffel <email@hidden>
- Date: Tue, 08 Apr 2014 19:41:56 -0400
using NSDocument w/ autosaves is a great way to go—lots of bang for your buck!
xml could open possibilities in terms of web potential.
moving history into your model will better facilitate portability [in case you’re thinking in this direction].
all good things for a cad app.
On Apr 8, 2014, at 6:24 PM, Rick Mann <email@hidden> wrote:
> Well, one of the issues is the data types. It's a bit clunky, but workable. There's one type of entity I want to create, a "Properties" table that maps strings to arbitrary value types. This would be trivial if I managed it myself, but Core Data doesn't let me have an entity attribute of type id, AFAIK. The other problem I'm facing, which is probably due to me misunderstanding NSPersistentDocument, is that I want my Library document to always autosave (in the sense that it programmatically saves after changes like adding a new Part object, rather than presenting the user with a save sheet). I haven't quite figured out how to do this. There are the saveToURL: methods, but what URL? It was opened from a file, it should know that. I just want to persist changes and clear the dirty state. Maybe I'd have the same issues with a "regular" NSDocument.
>
> The other thing (I meant to mention in the original email) is that I can't take advantage of autosave and async file operations, etc.
>
> BUT: Do I lose a lot of undo support? I've never tried to implement undo without Core Data.
>
> On Apr 8, 2014, at 15:15 , Mike Manzano <email@hidden> wrote:
>
>> Depends. Why are you “fighting” Core Data?
>>
>> Mike
>>
>>
>>
>> On Apr 8, 2014, 3:13:12 PM, Rick Mann <email@hidden> wrote:
>> This may prove to be an unproductive question to pose, so I apologize in advance.
>>
>> I'm generally a big fan of Core Data, but I'm developing a moderately complicated CAD app with libraries and design documents and such, and beginning to wonder if it would be easier to do if I weren't fighting Core Data. I'm wondering what the tradeoffs might be.
>>
>> If I were to dump Core Data, I'd keep the entire object graph in memory all the time, writing it out completely each time. I'd probably write XML, or some other text-based format (as much as I abhor text-based formats) because of the ease in diffing changes and using it with source control.
>>
>> As I write this, I realize that I can't just keep a whole document in memory; the library (which would be a collection of separate files on disk, but presented as a unified collection of content in the UI) could be very large and I'd rather not load in the whole thing. Nevertheless, I think that's doable.
>>
>> I'd have to handle relationships myself, but all the data types become easier to manage (I use a lot of C structs, well, really C++ structs).
>>
>> Thoughts? Thanks!
>>
>> --
>> Rick
>>
>>
>>
>> - signature.asc, 211 bytes
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
> --
> Rick
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden