Open Techn1x opened 1 year ago
Looking deeper, it might be specifically something to do with the mockUpdate(...).match(...).returns(...)
because it seems to work without the match/returns chains.
Either way, I still think giving the option to use string ids in factories would be beneficial
Also, I think string ids is be a requirement of ember-data 5 & 6.
It's a deprecation item here until ED6 https://deprecations.emberjs.com/ember-data/v5.x#toc_ember-data-deprecate-non-strict-id
We are deprecating this legacy support for numeric IDs.
But even when using ED with compatWith: '5.3'
it will fail with
Error: Assertion Failed: Resource IDs must be a non-empty string or null. Received '1'.
Plus 1
I'd like to use string ids across the board, as that's what my JSONAPI does and it's also what ember-data generally expects.
EDFG seems to always use number ids by default when using a factory. https://github.com/adopted-ember-addons/ember-data-factory-guy/blob/c4ccbaa70880084c13097c8c4ab6e4e1d6f5434b/addon/model-definition.js#L80-L82
That might have worked in the past, but I think ember-data is a bit more strict now. On ember-data 4.12.1, it seems that for a patch/update payload, if ED receives an id from the api (string) that does match match what is cached in its store (number), it fails with this error;
This can be replicated with code like the following;
The workaround is to set an id in the model when creating it
make('teacher', { id: 'my-string-id' })
but I've got a lot of tests to update if I go that path..I think the fix is to either force string ids from that nextId function, or give an option to users to set a flag in a factory to use string ids.