Data: How to re-create a deleted record (same ID)

[imhuytq]

I have a record with ID is sample_account. I have deleted it by using this code:

record.destroyRecord();

But when I re-create a new record with the same ID (sample_account), I received this error:

Assertion Failed: The id sample_account has already been used with another record for modelClass 'account'.

How can I re-create a deleted record with the same ID?

[olivierchatry]

I got the same issue while working on my undo - redo stack. The only way I found was :

this.store._removeFromIdMap(this.model._internalModel)

Note that you need to do that after destroyRecord. Also, it uses _ function, which means that it might not work from one version to the other.

I also think destroyed record should be removed from this map automatically.

[sly7-7]

I wonder if calling unloadRecord() would do the job here.

[imhuytq]

Thank @sly7-7 , use record.unloadRecord(); and it worked.
@olivierchatry I recommend you to use record.unloadRecord();.

[olivierchatry]

Ha! I uses store.unloadRecord and it was not working . Going to try with
record.

On 26 Jun 2017 8:40 am, "Huy TQ" [e-mail] wrote:

Closed #5014 https://github.com/emberjs/data/issues/5014.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/emberjs/data/issues/5014#event-1138099611, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABNXG3PutjzYm4MKvynaBqjB4H2vdYGcks5sH1JIgaJpZM4N9VN3
.

[anlumo]

unloadRecord doesn't trigger deleteRecord in the adapter and you can't both delete and unload the same record. Thus, I wouldn't consider this fixed, since the only solution is to access a private function and a private property.

[anlumo]

I also noticed just now that ember-data wreaks havoc with relationships in this situation, because there's a cache deep down in store.recordArrayManager._relationshipsPayloads._cache that is not cleaned up when a record is deleted. This causes some relationships to be formed automatically that are not in the model (and it even ignores inverse relationships at that).

EDIT: just found the function store._internalModelDestroyed that does clean up the relationships as well. This is supposed to be called from internalmodel.destroy, apparently ember-data never destroys the internal models?

[mrloop]

This is working for me

myRecord.destroyRecord().then( rec => rec.unloadRecord());

[JCBarry]

I am running into this as well. Creating a new record with a specific ID (using createRecord) before saving, calling deleteRecord removes the record from the store. However, if I try to re-create the record (createRecord) using the same ID -- I will receive this exception.

Since the record isn't saved at the data source, I don't think destroyRecord makes sense -- any reason that deleteRecord doesn't release the ID constraint from the data store?

[dennismende]

Hi, could some open the ticket again please?

I have the same problem with deleteRecord together with the id exception.

[anlumo]

It would be great to have this fixed. The workaround I posted above doesn't work with 3.5 any more, I'm currently looking for a new one.

I wonder how many projects are constantly leaking internalModels without realizing it.

EDIT: Apparently this issue is tracked in #5006.

[olivierchatry]

Same here, seems like since 3.5, my undo redo stack is broken. ( deleteRecord / createRecord with same id give me an error message about using the same id ).

[andrewcallahan]

I'm on Ember 3.8 and this is still an issue, and this is still the only way that works:

I got the same issue while working on my undo - redo stack. The only way I found was :

this.store._removeFromIdMap(this.model._internalModel)

Note that you need to do that after destroyRecord. Also, it uses ___ function, which means that it might not work from one version to the other.

I also think destroyed record should be removed from this map automatically.

[olivierchatry]

I think this needs to be re-open, as it is still not working.

[olivierchatry]

Still not working as 3.9.2

[runspired]

You have to unload the record after persisting the deletion

[olivierchatry]

Yes, that is what I'm doing.

        return model.save().then(
          () => model.unloadRecord()
        )

[runspired]

@olivierchatry with the delete call?

record.deleteRecord();
record.save().then(_ => record.unloadRecord());

[olivierchatry]

This is an "undo" action. The delete is done before saving. So yes, it is done.

In this code, undo / redo are called, then save. So deleteRecord() is called ( also the whole code is working as expected on 3.4.x, started to fails in 3.5.x

  redo() {
    this._createData()
  },
  undo() {
    const model = this.getModel()
    this._saveData()
    this.onDestroyModel(model)
    model.deleteRecord()
  },
  save() {
    const model = this._modelId ? this.getModel() : this.model
    if (model) {
      if (model.get('isDeleted')) {
        return model.save().then(
          () => model.unloadRecord()
        )
      } else if (model.get('isDestroyed') === false ) {
        return model.save().then(
          () => this._modelId = model.get('id')
        )
      }
    }
  }

[validkeys]

Can confirm this is also an issue on ember-data 3.10.0

[anlumo]

Well, there's an undocumented requirement that causes this issue. Whether it's an actual code bug or a documentation issue is up for interpretation.

You have to actively push all changes you get in an adapter back into the store from that adapter, otherwise the relationships of a changed record (unlike the attributes) will be in an unsaved state. This causes leaked objects all over the place, including the ids of deleted records.

[olivierchatry]

So being looking at the code, and from what I can see, it seems destroy is never called.
The function unloadRecord schedule a call on the destroy loop :

      if (this._scheduledDestroy === null) {
        this._scheduledDestroy = Ember.run.backburner.schedule('destroy', this, '_checkForOrphanedInternalModels');
      }

_scheduledDestroy is used to test if someone directly call createRecord with the same id right after, and if user do that, emberdata call destroySync, which actually destroy and remove the model from the internal model cache.

If not, then _checkForOrphanedInternalModels is called, which only does :

      this._isDematerializing = false;
      this._scheduledDestroy = null;

      if (this.isDestroyed) {
        return;
      }

My guess is that normally destroy should be called right after _checkForOrphanedInternalModels

Was wondering if maybe somethiing was missing after the

      if (this.isDestroyed) {
        return;
      }

like maybe a call to destroy?