3 ms·

Thanks for the comment Jeremy. What about this case (copying from my comment on my blog) "Also a ticket could be present in two different collections fetched f

Thanks for the comment Jeremy. What about this case (copying from my comment on my blog) "Also a ticket could be present in two different collections fetched from different urls. For example, the same ticket (id) could be in /tickets/all_tickets and /tickets/my_tickets. The book-keeping just keeps getting harder as your app grows"

jashkenas 15y ago
Sure -- let's look at this particular case. In your implementation, you're using the "name" property of the constructor function to namespace lookups in your global cache: instance = Backbone.CacheStore.get(this.name + "/" + attributes.id); ... relying on the "name" property simply won't work in older versions of IE, unfortunately. Here's one quick sketch of a way to build a "findOrCreate" that you can use on all of your ticket collections -- and also have a reference to all of your client-side loaded tickets if you ever need it. SB.TicketCollection = Backbone.Collection.extend({ findOrCreate: function(id) { var model = SB.Tickets.get(id) || new SB.Ticket({id: id}); this.add(model); return model; } }); SB.Tickets = new SB.TicketCollection; Now, whenever you use an SB.TicketCollection, you can get the appropriate behavior with "findOrCreate". This particular pattern isn't terribly useful for many applications because a model that consists of only an ID doesn't give you much to work with. But perhaps I'm not fully understanding your use case.
- prateekdayal 15y ago
  Let me explain my use case. We have several listings (Unassigned, My Tickets, All Tickets etc). A list view initializes a TicketList collection and then does the usual rendering etc. Also, once we render a listing we cache the rendered view so moving between them is snappy. Every listing basically fetches from a collection url (for instance /tickets/unassigned, /tickets/my_tickets etc). Let us say a ticket with id 10 is in two listings. If we do a .fetch() on one of the listings and the ticket with id 10 is updated (let's say the replies_count changed in the server), not only is the view corresponding to this listing updated, it is also updated for the other listings. If every listing was based on the same TicketList collection object, your solution would work well. However since different listings use different TicketList objects (initialized with a different url), I came up with the identity map solution.
  - crescentfresh 15y ago
    Have you considered filtering of "all tickets" in the client, for different subsets? Eg http://stackoverflow.com/q/6865316/172188 http://stackoverflow.com/q/6865316/172188
- Simucal 15y ago
  What would you do to solve this model-syncing in a situation where your model consisted of more than an id?

jashkenas 15y ago

Sure -- let's look at this particular case. In your implementation, you're using the "name" property of the constructor function to namespace lookups in your global cache: instance = Backbone.CacheStore.get(this.name + "/" + attributes.id); ... relying on the "name" property simply won't work in older versions of IE, unfortunately. Here's one quick sketch of a way to build a "findOrCreate" that you can use on all of your ticket collections -- and also have a reference to all of your client-side loaded tickets if you ever need it. SB.TicketCollection = Backbone.Collection.extend({ findOrCreate: function(id) { var model = SB.Tickets.get(id) || new SB.Ticket({id: id}); this.add(model); return model; } }); SB.Tickets = new SB.TicketCollection; Now, whenever you use an SB.TicketCollection, you can get the appropriate behavior with "findOrCreate". This particular pattern isn't terribly useful for many applications because a model that consists of only an ID doesn't give you much to work with. But perhaps I'm not fully understanding your use case.

prateekdayal 15y ago
Let me explain my use case. We have several listings (Unassigned, My Tickets, All Tickets etc). A list view initializes a TicketList collection and then does the usual rendering etc. Also, once we render a listing we cache the rendered view so moving between them is snappy. Every listing basically fetches from a collection url (for instance /tickets/unassigned, /tickets/my_tickets etc). Let us say a ticket with id 10 is in two listings. If we do a .fetch() on one of the listings and the ticket with id 10 is updated (let's say the replies_count changed in the server), not only is the view corresponding to this listing updated, it is also updated for the other listings. If every listing was based on the same TicketList collection object, your solution would work well. However since different listings use different TicketList objects (initialized with a different url), I came up with the identity map solution.
- crescentfresh 15y ago
  Have you considered filtering of "all tickets" in the client, for different subsets? Eg http://stackoverflow.com/q/6865316/172188 http://stackoverflow.com/q/6865316/172188
Simucal 15y ago
What would you do to solve this model-syncing in a situation where your model consisted of more than an id?