Download and parse user lists #1699
Conversation
|
Also to address some of your questions in the description:
|
|
Wow, creating a child entity is genius and I'm not sure why I didn't think of it. Did I even know that existed? I can neither confirm nor deny. I'd especially like to address the EventProcessor return value and handle deletes before merging, so I'll try the child entity in this PR and see how it goes. |
|
Needs re-review since I made AuthorList a child entity and subclass of Event. |
|
👀 |
Nos/Service/Relay/RelayService.swift
Outdated
| @@ -269,10 +269,27 @@ extension RelayService { | |||
| return await fetchEvents(matching: contactFilter) | |||
| } | |||
|
|
|||
| func requestFollowSets( | |||
There was a problem hiding this comment.
| func requestFollowSets( | |
| func requestAuthorLists( |
There was a problem hiding this comment.
So this specifically requests only kind 30000 Follow Set events, which is why I named it this way. I did consider AuthorLists instead, and I suppose if we want to add more kinds to the Filter in the future, we'd want that to be the name. I guess for now this does fetch all AuthorLists we support, which happens to be only kind 30000 Follow Sets, so I'm good with the rename.
| <relationship name="follows" optional="YES" toMany="YES" deletionRule="Cascade" destinationEntity="Follow" inverseName="source" inverseEntity="Follow"/> | ||
| <relationship name="includedInLists" optional="YES" toMany="YES" deletionRule="Nullify" destinationEntity="AuthorList" inverseName="authors" inverseEntity="AuthorList"/> | ||
| <relationship name="incomingNotifications" optional="YES" maxCount="1" deletionRule="Nullify" destinationEntity="NosNotification" inverseName="user" inverseEntity="NosNotification"/> | ||
| <relationship name="lists" optional="YES" toMany="YES" deletionRule="Nullify" destinationEntity="AuthorList"/> |
There was a problem hiding this comment.
Xcode is unhappy that this "lists" relationship has no inverse. It seems the same as "includedInLists" though. Did you mean to have both of them?
There was a problem hiding this comment.
An Author can have multiple AuthorLists that they own. In each AuthorList is an array of Authors. So there are two relationships here, I think, and I suppose I need to handle that.
There was a problem hiding this comment.
But I see now that if I set the inverse of lists to author, then events no longer has the inverse set to author. So that's a problem.
There was a problem hiding this comment.
I went ahead and added another relationship to AuthorList: owner, which goes to Author, and allows us to set the Author inverse to owner.
# Conflicts: # CHANGELOG.md # Nos.xcodeproj/project.pbxproj
Issues covered
https://github.com/verse-pbc/issues/issues/49
Description
Fetches user lists of kind 30000 and stores them in Core Data when the user's profile is displayed.
How to test
Either:
A. Run unit tests
Or:
B. Run the app, find a profile of a user who has lists (
npub1yl8jc6znttslcpj3p6p8vuq98awu6w0xh4lqtu0lkjr772kpx4ysfqvz34), then inspect Core DataTo Do
nilis weird.In order to track deletes, I think we'll need to look for a plain old Event of kind 5, then follow the same logic we do for finding the Event, but this time, find the AuthorList. We probably need to add a deletedOn to AuthorList to match the one on Event.
In continuing to work through this To Do list, I'm starting to wonder if we should even have a separate AuthorList entity in Core Data. We should certainly have a different model, but I'm not sure about the Core Data entity. There's a lot in common between the new AuthorList and Event in Core Data, and it feels a little weird to have a new entity there when it's just a plain old event like everything else. Unless, of course, we're working towards having separate entities for different types of events.