Description

<!-- insert description here -->

Notes for the release

<!-- If this PR should be described in the Ember release blog post please briefly describe what should be shared. -->

Currently this PR is design-proposal-as-documentation for adding reusable scenarios to Holodeck (called ... wait for it ... HoloPrograms) that make it easy to quickly write tests or develop against it.

Rendered

maybe unblock CI?

Backports all changes to the @ember-data/request package from 5.x as of tag 5.5.0-alpha.11

related to #9013

these tests demonstrate the unloadAll(<type>) edge case described in #9151

After debugging these tests, I've reached the conclusion this issue cannot be reasonably addressed without a major rewrite of our GC behavior. The unload APIs have always been a poor-man's escape hatch with tons of cav...

Replaces @ember/debug with @ember-data/macros

Currently only handles assert as we will need to introduce deprecation infra for warn and deprecate.

resolves #9123

resolves #9111 resolves #9104

resolves #9114

resolves #9127

The discussion in #9127 made clear we could document a few things better and that a couple of additional hooks would be useful.

resolves #9107 resolves #9118

should resolve the floating dependency test scenario failures

This PR improves belongsTo and hasMany references by

• overhauling their documentation
• improving the associated documentation on Model for retrieving a relationship reference
• fixing some bugs in their push signatures that occurred due to a past incompletely cleaned up deprecation
• ...

resolves #9168

an attempt at a minimal upgrade to the cache before going all-in on #8315

resolves #1699

If anyone happens to still be doing Store.extend we can restore with a deprecation. Extending the Store as a pattern was rare enough until well into Octane that likely this is safe-enough.

I noticed while migrating some things away from EmberObject (which debounces destroy) that destroy was being triggered more than once due to this. It appears the upstream change has long-since landed and we can remove this and speed up everyone's tests <3

uses the approach proven out by @ember-data/{tracking|request|store} for @ember-data/{adapter|serializer|model|record-data}

@ember-data/canary-features, @ember-data/private-build-infra and ember-data will require more unique approaches.

progress for #8103

Extracts the graph logic into a standalone package per emberjs/rfcs#854

resolve #7343

resolves #5882 by expanding tests to show the format works

resolves #3757

resolves #7371

In emberjs/data#8101 it was noted that the error message provided here did not give enough context for users to understand the issue was due to the Fastboot environment and the existence of the fastbootDependencies allow list. This should help greatly with that.

Ref: https://github.com/emberjs...

resolves #2786

resolves #7917

resolves #8203

also defends against cache duplicate notifications for removals since user-land API calls could otherwise similarly trigger this.

resolves #8327

resolves #7969

resolves #7086

Makes notifications public and adds docs as described by emberjs/rfcs#854

note this feature was already public but not accessible by this means

one of many steps for emberjs/rfcs#854

As discussed OOB with @hjdivad, this PR asserts that you cannot model.set('id', '1').

For client-side creation with ID, ID must be passed in via store.createRecord('foo', { id: '1' });

cc @dnachev

use _push instead of mapping over push result to get internal models

store.reloadRecord => store._reloadRecord

Necessary for test helpers to clean state.

cc @chadhietala

Replaces #4667 with a version that takes more commits so we preserve more of the history of where code came from.

WIP Not finished porting that PR.

When benchmarking the micro queues for store._push I realized that I wasn't including related records in the payload anymore, this fixes that for the one scenario in the config but should be fixed for more of them long term.

…know if we were improving the cost of the lookups

… materialization as this is now so lazy that it must be forced, this makes the benchmark force it so that we can continue to measure improvement within materialization

Notes:

• was split off from the micro-queue work in #4668 so we could benchmark separately
• Usage this replaces was a mis-use of run.join
• This fix doesn't show any improvement in benchmark range at a glance
• But the fix does tighten the cluster of values within the range in a good direc...

With #4698 having landed, it's potentially possible we can remove some if not all calls to store._adapterRun. This PR currently removes all calls, leading to a small handful of failed tests which I'm investigating. I'll also run it against LI's test suite once those pass (if I can make them pa...

Needs benchmarking, review, may have been too aggressive in _modelFor use, dislike that modelFactoryFor is public, should discuss.

There wasn't really a good reason for this singleton being an Ember.Object (it's not resolved / not in the container / no ember-y things in use), and converting it shaves 33% off it's instantiation time in addition to giving us nice es6 syntax (1.53ms => .97ms).

Was working on cleaning up some things and just felt this could use a facelift. This isn't for perf, but I'm going to try to isolate it in a profile anyway because I'm personally curious the overall effects of:

• not setting things on the prototype that we're just going to override in the cons...

A recent feature flag change cause some of my instrumentation to follow different code paths and resulted in different than expected results. These tweaks both account for that and are a bit more resilient. I've back-ported them to various branches I'm using for comparisons to keep measurements...

TL;DR spin up less, schedule less, batch more things, cleaner profiles :)

Right now this fails on the tests around support for preloading relationships when doing findRecord, digging in on that.

This is the beginnings of revisiting the objects / patterns used to manage the relationship layer in ember-data.

• [ ] treat Relationship as an abstract base class
• [ ] simpler BelongsToRelationship class
• [ ] explicit ImplictRelationship class
• [ ] simpler HasManyRelationship cl...