Override id in Apollo in-memory-cache

Help
,
1

In an Apollo based Webapp, the user is provided the functionality to change the identifier of an entity - that’s the 'id` identifier filed in graphql defs - using a server api.
At the moment of that operation, current Apollo in-memory-cache already contains a number of references about the updating-id-entity in many contexts:

  • main cached entity reference (at root of cache.data.data )
  • various references in different other entities (via __ref field)

all those references would brake, as well as any query watch involving the updating-entity-id

Query watching issues can be resolved applicatively.

about the cache, I didn’t find any built-in feature for this use-case,
so I was wondering if I could manage that manually…

I would manually modify the cache.data.data object :

  • clone the top-level entity renaming the top level prop-name accordingly to the new id
  • delete the original
  • scan the whole cache obj for any __ref and change the value accordingly

Any issue with this approach?
am I missing somenthin?
how likely a future lib upgrade may brake-change?
is there a cleaner approach?

2

For various reasons, many of which you’ve listed yourself, this isn’t really a good idea. The point of an identifier is that it never changes and that it can always identify a particular entity. That said, is it possible for your objects to be identified by a different (unchanging) field or by a combination of fields? If so, you can specify these in a type policy.

3

there’s indeed a permanent ID server side
but the point of the use case is to avoid publishing it and making it transient by user edit.
IDs actually “never changes and that it can always identify a particular entity” …
… until a user edits it ^^’

4

All right, so technically changing an object’s id could be interpreted as deleting it and re-inserting it. If you treat it that way in the cache, you should be fine. Delete the object with the old id from the cache (along with its references) and insert it again with the new id (and add it to where the old object used to be referenced). I think that would be a bit more in the spirit of the cache implementation, as opposed to manually changing the __ref strings.

5

Yep, that’s a correct interpretation (at least from cache view)
The point is to restore logic consistency in already cached data.
so, I guess the prcedure should be as follows:

  • insert*() a copy of the old-id-object with new id (* what method ?)
  • scan the whole cache object and on each old-id-__ref apply a modify() with the new id
  • evict() the old-id-object

… but … what about extract()-restore()?
what if I extract() the cache, scan and properly modify the result, and then restore() it ?

a note about my use case:
it could be generalized as an issue about accessing content by slug in a CMS.
CMS typically identify content by slugs, and slugs can be typically edited
one way to workaround the issue is to publish and manage both ids (slug and permanent-id) client-side, having the perm-id as graphql-id and the slug as a Type prop.
assuming slugs and urls do not embed the ID, it’s possible to manage in some slightly cumbersome ways.