davidevincenzi / datalayer Goto Github PK

DetailViewController.swift:31

    var detailItem: EventType? {
        didSet {
            if let detail = detailItem {
                userItem = dataLayer?.userOfEvent(detail)
            } else {
                userItem = nil
            }
            configureView()
        }
    }

This can become very "nested" when trying to get through several relationships level (eg. topic.documents.first?.revision). We'll also end up with lots of these methods.
And we lose the main benefit of having an ORM behind.

I was thinking wether we can have a solution where the struct itself provides the relationship. But then we would have to have a reference to the managed object inside the struct (eg. the NSManagedObjectID).

@nfgrilo @aleksanderk I added the User entity and its relationship with the Event. About thread safety, do you have an example where this may be an issue?

Another potential unconvenient thing to do in the Struct solution is about updating and refreshing the objects.

In the protocols solution is as easy as this c693871#diff-a38d89077d3b2d4ab96a1c2d4e1e34a5R45

I added the same method in the structs branch: 7abbcd2#diff-a38d89077d3b2d4ab96a1c2d4e1e34a5R42
What's the easiest way to do that with structs?

Just wanted to note that thread safety imo is really something we need to live without. Even in the Struct solution, we need to be careful when updating the entities, as this can lead to crashes, as you can see in the latest commit in the data_layer_with_structs branch: 7d57bc0

Basically with Structs we're safe when reading properties, but not when writing them.
With Protocols, this is never safe. I tried to workaround it with this commit 550a720 and it works, you can read and write in background threads. But it requires lots of boilerplate code, so I don't know if it's worth the effort.