Open runspired opened 4 years ago
Parallel Efforts that assist this effort (the first three are already tasks for Project Trim)
cc @sly7-7 This is an effort I'm pairing with @skaterdav85 on to improve relationships that should help you greatly :) If you have the ability to contribute to it to help resolve your performance issues with relationships that would be awesome!
👋
I removed the Diff util in #8550 which we may end up wanting later. It was currently unused so seemed better to drop for now.
The main change I want to see before marking the API as complete is a story around pagination. I began a spike for it in #9320.
The largest unanswered question is what the underlying page storage mechanism should be, and how (with it) to account for the potential for someone to fetch an arbitrary page of the relationship (where arbitrary means that a gap in pages exists between that page and any pages connected to the first or last page).
Pagination is so varied it is necessarily hard to support arbitrary pages (whereas it is relatively easy to support first/prev/next/last as pointers for iteration of a linked list).
Potential data structures include:
Tracking Issue for Improvements to the Performance, Reliability, and Encapsulation of the Relationship Layer.
Pre-Refactor
Stage 1
recordData.isNew
by the relationship state classesthis.recordData
in those classescreate
andget
vs stealing from RecordDataStage 2
resource._relationships
should be removed in favor of a WeakMap for the store/InternalModel to access RelationshipStaterelationships.perform
with the operation on the relationship. This method will then translate the operation into the legacy method calls on the relationship in a switch statement.relationships.query
graphFor(storeWrapper).<perform|query>(...)
Stage 3
Stage 4
Stage 5
isEmpty
checkStage 6
perform/query
public for relationships on RecordDataRecordData
implementations to make use of the relationship-graph if desired