--- In [email protected], "Jeff Glass" <[EMAIL PROTECTED]> wrote: > > I have some questions about manual sync with LCDS 2.5.1. > > --- In [email protected], "Jeff Vroom" <jvroom@> wrote: > > > One other difference is that the "refresh fill" process - i.e. > > where the server refreshes fill methods after an insert or update > > or explicit "refreshFill" call is made on the server does not work > > with manual sync. Since the server has no knowledge of what fills > > each client is actively managing and does not cache its current > > set of ids, it can't refresh it. > > But the assembler doesn't know what fills are active, either. Or am I > missing something? The assembler can keep track of a client's initial > use of a fill (by saving the fillParams argument to the assembler's > fill method), but can the assembler get notification when the fill is > no longer being used (e.g., when the client goes away)? >
Yes, this is the case. The auto sync mechanism is what keeps track of which fills clients are looking at specifically. You would have to duplicate this logic and it is not trivial. To solve this generally is a bit tricky - you need to watch when fills are made, associate them with a session and remove that when the session expires. You might also need to add a remote object call to release the collection if the client stops looking at the results of that query. There could be short cuts based on how your app uses queries and what changes might affect those queries. Clearly this is something we need to address by supporting the "paged fill" functionality with auto-sync=true. > > You can still update queries by using the > > DataServiceTransaction.addItemToFill and removeItemFromFill methods. > > In my experimentation, you have to call addItemToFill and > removeItemFromFill with the *exact* fill parameters (unlike the > matching that is done by refreshFill). Hence the need to keep track of > which fills are active. > > Also, in my experimentation, the client only seems to get the > collection-change event if the addItemToFill call has position=-1. Is > that expected? In my application, the fills have a sort value, meaning > that the new item could be in different positions in different fills > anyway, so what I think the client should do is to just start the fill > over again when an item is created. How would the assembler notify the > client that it should do that? (That is, how do I get something > similar to a refreshFill method returning EXECUTE_FILL in the > auto-sync case?) > This sounds like a bug which is fixed in a hotfix we have. I think that the addItemToFill method would fail if the index was not -1 and there was no sequence. Again, we just don't have a great way to "refresh" an entire sequence when auto sync is false. It sounds like you really need the auto- sync=true with the "paged fill" support. > > Of course the other server side methods updateItem, createItem, and > > deleteItem also still work though make sure that any use of these > > apis also supply the producerSubtopics or producerDefaultHeaders > > needed to route these changes to the right clients. > > What exactly are createItem and deleteItem good for in the manual- sync > case? They're not pushing anything to the clients. > You can route createItem messages to other clients but you also need to push some updateCollection or updateItem to add a reference to that item for it to show up someplace. The deleteItem should just be handled automatically... when a delete is pushed to a client, it is automatically removed from any refernces.
