Open mathebox opened 7 years ago
Hey @mathebox, thanks for making a start at this. I was trying to pickup where you left off.
For starters I wasn't able to implement the protocol without having to conform entirely to Resource
protocol. This seems to be due extension Resource
not being public where as the Resource
protocol is.
Also seems to break the ability to sequence a bunch of BrightFuture futures:
[self.spine.delete(self.fitting),self.spine.save(self.fitting)].sequence().onSuccess(callback: { (resources) in
Hello guys. I have worked on a a couple ORM's and wonder if there is anything I could lend a hand with. We are looking at using this library but the "offline mode" abilities really should be moved to CoreData and thus, here we are.
After doing some research into this issue for our own uses. We have come up with an idea of using spine in concert with core data, abstracted behind NSIncrementalStore. This will allow us to use core data natively with the ability to have our "back-end" be a spine-compliant API. AFNetworking once had a AFIncrementalStore that used AFRESTClient. I believe this could be easily ported to be used with spine. The only thing that would make sense to me is allow the incremental store the ability to create a "Resource" Class by inspecting a NSManagedObject for which fields it has and what types they are when it begins the store in loadMetadata. This would prevent the need for both and give a user wanting to persist with core-data a backend connected to their api. I am hoping that @wvteijlingen could guide me in the right direction as to the dynamic creation of a resource.
@mmoonport hey. I've forked this PR branch into our own & have written persistence using Realm. It isn't amazing; but it works for our needs. I'm keen to write a more robust persistence layer on-top of Spine; but it seems development & activity has gone stale.
Hi @wvteijlingen,
this is my attempt to change
Resource
to a protocol. Please have a look. The code is still kind of messy and really not ready to be merged. But the tests are passing :tada:I made the following changes
Resource
to protocolNSCoding
conformance ofResource
. Each implementation should handle this on its own.ZeWo/Reflection
(see #152) for getting and setting properties. They do not provide a dynamic framework which is necessary for carthage. So I usedcarthage update --no-build
and created a workspace for Spine and a project for Reflection.Field
instances due to generic types. This also preventsswitch
statements of fields of resources.Field
implementation to protocol-struct-combination. (We need to these protocols to hide the generic types, e.g. theRelationship
protocol)Resource
needs aresourceData
property.Next steps / further improvements
FieldData
struct (similar toResourceData
) to avoid code repetitiondescription
anddebugDescription
toResource
Additional notes We should distinguish between
Attribute
andRelationship
ofResource
objects. Currently they are returned asField
instances. Therefore theField
protocol contains some methods which are only used when working with relationships.What's do we need to support CoreData? (This should probably be moved to a separate issue.)
ResourceCollection
objects. Maybe we could provide the links etc. via methods onResource
.URL
. We have to check the type of the property (String vs URL). This should be handled by theURLAttribute
.Hopefully I have covered every change I made. What are your thoughts?