Results 1 to 5 of 5

Thread: Store::sync() runs destroy requests on proxy for Models that are already destroyed

    Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Ext JS Premium Member Gjslick's Avatar
    Join Date
    Feb 2009
    Location
    NJ, USA
    Posts
    129

    Default Store::sync() runs destroy requests on proxy for Models that are already destroyed

    Ext version tested:
    • Ext 4.1.1
    Browser versions tested against:
    • Chrome 21
    • IE8
    • FF14 (firebug 1.10 installed)
    Description:
    • When a Model is destroyed manually (by calling model.destroy()), any Stores that own the model still keep the Model in its records collection. A case can be made for this behavior, such as maintaining a list of deleted items.

      However, in the case that we want to destroy a model manually, and then remove it from any stores that own it, then we have the following problem: calling store.sync() on those store(s) at a later time causes the store to re-destroy the same already-destroyed model through its proxy.
    Steps to reproduce the problem:
    • Go to this jsfiddle: http://jsfiddle.net/fUy3a/10/
      Notice that the model is destroyed manually with model.destroy(), and upon its destruction, it is removed from the store (with store.remove(model)). The store is then sync'd, creating the second line of debugging output which shows Proxy::destroy() being called again.
    The result that was expected:
    • The model should have only been destroyed through a proxy just once - the first time it was destroyed via model.destroy().
    The result that occurs instead:
    • The model is destroyed twice.
    See this URL for live test case:
    Possible fix:
    • Models should probably know when they are destroyed. A flag could be set when they are. Then AbstractStore::sync() (or possibly rather, AbstractStore::getRemovedRecords()) could check that destroyed flag before it tries to re-destroy the Model.

  2. #2
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,448

    Default

    You shouldn't use model.destroy unless the model is outside of a store. For this, you should just remove the model from the store and sync the store to do the destroy operation.
    Mitchell Simoens @LikelyMitch

    Check out my GitHub:
    https://github.com/mitchellsimoens

    Posts are my own, not any current, past or future employer's.

  3. #3
    Ext JS Premium Member Gjslick's Avatar
    Join Date
    Feb 2009
    Location
    NJ, USA
    Posts
    129

    Default

    Hey Mitchell,

    Thanks for your reply, but here's the thing: we don't want to remove the model from the store *until* it has been destroyed on the server. Basically, views update immediately when a model is removed, and we have the models in a grid. If the sync operation to destroy the model fails, then we'd have to re-add the model to the store to give the user the ability to try to delete it again... That's nasty, and confusing for the user. We basically want to confirm that the user wants to delete a record, then show a mask over the confirm dialog while the request is processing.

    In general though, the API should be hard to be misused, and something available on the model level (the destroy method) should work regardless of how/where that model is used. Therefore, client code should be able to destroy a model without having any knowledge of what store(s) it is in, or even if it is in any store at all. In any case, the model shouldn't be destroyed on the server more than once.

    -Greg

  4. #4
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,448

    Default

    To stop the view from changing, store.suspendEvents() and resumeEvents()
    Mitchell Simoens @LikelyMitch

    Check out my GitHub:
    https://github.com/mitchellsimoens

    Posts are my own, not any current, past or future employer's.

  5. #5
    Ext JS Premium Member Gjslick's Avatar
    Join Date
    Feb 2009
    Location
    NJ, USA
    Posts
    129

    Default

    Hackity hack hack hack, lol. What if there are other events on the store (such as background updates / additions) that we do want to respond to while the destroy request is taking place?

    Also, there are some other issues to consider as well. For instance, responding to the completion of a sync on a store is difficult at best. Many operations may execute when the store is sync'd, including create, update, and other destroy operations. Some may succeed and some may fail, so finding out if just the destroy operation in question has been completed successfully becomes quite ugly (involves looping over the Operation objects of the Ext.data.Batch object, checking each for success, looping over the models in each Operation, and finally, testing each of the models for the model in question - 4 levels of nested control statements and the 5th level for the code we want to execute in this case). And upon failure of a particular destroy operation, we still have to re-add the model back into the store(s) in which it belongs to. Taking it away only to add it back is just a little bit silly... (not to mention not straightforward code).

    And again, this is still assuming that the code which is responsible for destroying the model even knows about the store(s) that the model belongs to in the first place.

    -Greg

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •