Re: CoreData questions: How to reset NSManagedObject, how to "Un-manage" an NSManagedObject.
Re: CoreData questions: How to reset NSManagedObject, how to "Un-manage" an NSManagedObject.
- Subject: Re: CoreData questions: How to reset NSManagedObject, how to "Un-manage" an NSManagedObject.
- From: Andreas Grosam <email@hidden>
- Date: Thu, 24 Mar 2011 22:03:37 +0100
On Mar 23, 2011, at 8:49 PM, Motti Shneor wrote:
> Thanks Andreas, for such a complete and helpful answer.
>
> Regarding reset issue, I was curious --- after all, NSManagedObject gets its initial dictionary from the Model definition somehow, doesn't it?
(see Quincey's reply)
> why can't I do it, or even better, why isn't it implemented as a NSManagedObject API?
Unfortunately, there is no convenience method which would reset a managed object to its default values defined in the model.
>
> I find resetting an object a very basic functionality. I'll see how I can write some generic code to do it for all my entities.
... but you can certainly use the entity description for getting the default values. However, this is much more elaborated than just setting up a dictionary holding the initial state. But I agree, I can think of a generic solution. So, you might go this route and implement your own reset method for your custom entity class.
>
> Regarding the other issue.... (sigh)
>
> Well, we are contractors for a big company. They have their old server-client code modules, and they try to keep them cross-platform (Yup, Windows). That's why they refrain from any Core-Data direct calls in the background thread client code. It's not because it's on a thread, it's because this code is not "Mac only" code.
OK, just let us assume, your platform agnostic code handles the import of data objects, running in a separate thread. The result is one or more arrays of "records" existing in some intermediate form. These may be in RAM or on a file, doesn't matter. If I understood you correctly, your "internal Mac specific task" is now to read these "records" and create managed objects from them:
> We DO employ the technique you demonstrated, (a flavor of it) and we do have 2 contexts (one writing, one reading) to achieve transactional behavior on the UI side, (updating the UI on controllable sets of changes).
This sounds fine.
>
> The big-company guys, simply duplicated all the model classes generated from the model, polluting the namespace, and introducing pitfalls all over the place (If the model changes, it is no longer in sync with those data objects). I was hoping to propose a solution that will eliminate those duplicate model classes.
Uhm, I fear we are entering a wide, wide area of complex problems now, which may include problems from distributed databases, synchronizing, client-specific restrictions, etc.,etc. I cannot give a specific answer to this problem. It depends too much on your actual requirements.
I can imagine that there may be client-applications which can handle virtual any model, so model changes wouldn't hurt or wouldn't make the client unusable. But these applications cannot perform more complex business logic. So, viewing any sort of hierarchically structured data could have a generic solution. But if you want to do more complex things, like creating a sales order - you should know a priory what your data is and what the corresponding business logic is.
Simply put, if you have a client application which essentially does some useful and complex stuff, you cannot change the model on neither side (namely change the specification or the API) without expecting any issues. So, you should agree on an API manifested in a specification.
Well, I would suggest to use a client-platform independent model on the server side. That is, the server implements its (private) data model and the corresponding business logic. The server here is the "authoritative" regarding business logic. While the server side internal model may be private, the server communicates through an API defined in the specification. This could be materialized in sending objects in a JSON format, for instance.
On the client side, there is a client specific data model which is quite similar to the server side model exposed by the specification (including business logic) but may be tailored to optimally meet client side requirements and restrictions. The client as well may implement all or part of the business logic. How much of it depends whether you can communicate with the server all the time, or if you want to be able to operate in "offline" mode.
The server is the *authority* over what is created, deleted or modified in its store. In its simplest form, the client would not implement any complex business logic, just acting as a "view" then sending "form data".
If you have to meet business logic AND if your client shall operate offline, the scenario becomes exponentially more complex. "Importing" then becomes "synchronizing" - and this is a very complex topic. With business logic, synchronizing must not happen on the database level, it must happen at the business logic level. In this more complex form, the client would fully replicate the business logic implemented on the authoritative server - and would then be able to operate independently. Nonetheless, the server does perform all validations when the client and server models will be synchronized.
A RESTful API would make it much easier to handle client and sever side actions on the objects, since you just have the "CRUD" methods. Keeping the data synchronized is then much easier (but unfortunately, not that easy at all).
So, having said this, and also assuming you implement it according an API, I cannot see anything on the client side which requires anything to be implemented in a "specific" way. Just use Core Data, threads, and as many contexts as you need on the Mac ;)
Of, course you can use the portable code which imports the data coming from the server - but considering the vast other issues and problems which can arise here in this scenario, this should be a minor thing. ;)
>
> Thanks again!
> Motti.
>
> On 23/03/2011, at 20:27, Andreas Grosam wrote:
>
>> On Mar 23, 2011, at 8:21 AM, Motti Shneor wrote:
>>
>>> Hi.
>>>
>>> 1. When you create an NSManagedObject, it is initialized with default values defined in the model. How can I reset an existing NSManagedObject to these default values?
>> Unless there is a better way, I would suggest to use a dictionary representation of a freshly created managed object through taking a "snap-shot" of this object using dictionaryWithValuesForKeys:. Then "reset" any managed object by sending it setValuesForKeysWithDictionary:. You may declare this dictionary as a class variable of your custom class and initialize it once when you create the first managed object. You may get the key paths using the entity description.
>>
>>>
>>> 2. We have a multithreaded application, and we only keep one core-data context. Our network-related code receives data in a background thread, but is unable to write it to the model directly. So it saves it in some intermediate data object, and passes it to the main-thread for writing into the model.
>>> I would like to use an NSManagedObject to replace the intermediate data object --- It is quite ugly to have duplicated model classes definition for everything. My question:
>> I wonder why you cannot modify the model (that is save a context) within the background thread. Business logic should be honored regardless of the thread. So, usually you would do the following:
>>
>>>
>>> Can I somehow detach an NSManagedObject from its context, and use it in an "Unmanaged" way?
>> No, a managed object must be registered with a managed object context.
>>> Hopefully I can later attach it to the context, or create another NSManagedOBject from its data?
>> You could use a dictionary representation and initialize a managed object from it.
>>
>> Regards
>> Andreas
>
> Motti Shneor,
> Spectrum Reflections LTD.
> ---
> ceterum censeo microsoftiem delendam esse
_______________________________________________
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