Closed benwoodward closed 9 years ago
So you're saying that the way to do it is to use and intermediary object (custom base class) that implements ResourceProtocol, and write logic that persists Realm models using data from the intermediary object?
When Spine deserializes the resources from a json representation, it must then also deserialize onto existing resources that are already in the store. This can quickly complicate the process, especially when hooking up relationships.
You could write some custom logic to do this. I don't know if Realm supports such a thing as an NSIncrementalStore in Core Data. If it does, I think would be a way to go for now.
When Spine deserializes the resources from a json representation, it must then also deserialize onto existing resources that are already in the store. This can quickly complicate the process, especially when hooking up relationships.
Wouldn't I have this issue regardless? I would need to hook up relationships in Realm even if parsing JSON into Realm objects in a very manual way using [NSDictionary]
s and a bunch of if let
s.
What is the problem that NSIncrementalStore solves? As far as I can tell, it acts as an adapter between data and the database, making the database swappable.
Yeah that would pretty much be the same. Only now you use Spine Resources instead of Dictionaries.
NSIncrementalStore is a backing store for Core Data, well suited for connecting to a remote API. When you request a Core Data managed object, your incremental store is responsible for retrieving it from the API. When combining this with a local store, it serves as a nice back-end to the regular Core Data API. Example, although abandoned: https://github.com/AFNetworking/AFIncrementalStore
But really if you're using Realm all this Core Data stuff doesn't matter anyway :).
I'll close this issue for now. If there is anything else relating to Spine and Realm, feel free to reopen it or create a new issue :).
@wvteijlingen would you mind sharing some more details on ResourceProtocol protocol?
Ah it was my understanding that mention of persisting in the docs meant persisting to disk. On further understanding on the above; may I ask why it wouldn't be possible to have the ResourceFactory fetch existing objects from a resource store?
I removed ResourceProtocol because it clashed with the generics system. Resource class now must inherit from Resource
. There is no built in mechanism to persist to disk. I think it should be possible to modify ResourceFactory and have it use a real store. Not sure what the implications would be for overriding relationships etc. though. Also if we implement such a thing, we probably need better callbacks so that we can fire callbacks for loaded from disk and then loaded from server after that.
I haven't used Realm myself, but you can use Spine with custom base classes by implementing ResourceProtocol. The main issue I see is that Realm is a resource store, while Spine doesn't use a store. In most cases it instantiates new objects for every resource received. So to properly support Realm I think we need to do some refactoring to a store-based model.