Grid unbuffered mode not working as documented

In the Grid documentation for Vaadin 7
, it says the following:
The editor has no buttons and all changed data is committed directly to the container. If another row is clicked, the editor for the current row is closed and a row editor for the clicked row is opened.

Note that is says “directly”, and implies that the container is updated immediately. But in my case it is not saving my changes to the container - when I try to go through the lines to apply changes to my database, I don’t see those data changes. What is happening?

I even tried changed it to “buffered” mode. In this case, I see it in the container, but don’t see the changes in the Grid until I refresh the grid. This is kind of weird, but I guess it might make sense. That said, why is my typed changes not applied immediately to what I see on the screen once I click “Save”.

What container you use? Sounds like you have probably issue with data binding, e.g. hash code or something like that. See remarks in BeanItemContainer docs:

BeanItemContainer, since I am dealing with beans and that seemed the best container for what I needed.

So you are thinking that something I am doing is changing the hashcode value? Because the initial binding works ( since I can see the data in the grid visually ), only impacted when I try to change the value in the column.

In fact, I don’t know if this helps, but in unbuffered mode, the “setter” of the data element(s) I changed never gets called after I neter edit mode.

Investigating hashCode stuff now, adding logs, etc, to see if that reveals anything. Definitely worth checking.

Ok, I just realized I use BeanItemContainer for another Grid and it works fine for either buffered or unbuffered modes. Now the Grid that does not work involves a far more complex bean, and I actually override the sort method. So in order to determine if you theory is right or wrong, what would I need to look for?

Still having a problem. I could really use some help on how to prove or disprove Tatu’s theory.

So far I have done the following, with no improvement:

  • Simplified my bean as much as possible
  • Added/defined a hashCode/equals method pair for my bean
  • Tried with buffered and unbuffered mode
  • Editting either a selected or unselected line does not help - same problem either way ( was not really expecting this to matter, but had to try )

As per my comments earlier, I have another BeanItemContainer based Grid that works fine in bode modes.

I know in this non-working case the setters are not called unless “buffered” mode is set, but even here the UI does not show the change right away. I can prove it with breakpoints in Eclipse. The getters are called when load the Grid/container inititially, and the setters are called when I do explicit setting of data via BeanUtils.copyProperties or calling the setter.

What is really bugging me is that “buffered” ALMOST works - the only thing that is failing is the visual update of the screen. In fact, I see the following sequence of events on “Save”:

  1. Call getter, getting old values ( startTransaction in field group, it looks like )
  2. Call setter, setting new values
  3. Call getter, getting new values ( not sure if this is important, but eventhough I clicked Save, this “getter” call happens when the discard method is called,
    see stack trace below
WrappedReplenishmentOrder.getNewResizedBinQtyLong() line: 229 (out of synch)    
GeneratedMethodAccessor2024.invoke(Object, Object) line: not available    
DelegatingMethodAccessorImpl.invoke(Object, Object) line: 43    
Method.invoke(Object, Object...) line: 497    
MethodProperty<T>.getValue() line: 593    
TransactionalPropertyWrapper<T>.getValue() line: 87    
TextField(AbstractField<T>).getDataSourceValue() line: 307    
TextField(AbstractField<T>).updateValueFromDataSource() line: 1672    
TextField(AbstractField<T>).discard() line: 297    
Grid$CustomFieldGroup(FieldGroup).discard() line: 638    
Grid.doCancelEditor() line: 7117    
Grid$4.cancel(int) line: 4935  
NativeMethodAccessorImpl.invoke0(Method, Object, Object) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object) line: 62    
DelegatingMethodAccessorImpl.invoke(Object, Object) line: 43    
Method.invoke(Object, Object...) line: 497    
ServerRpcManager<T>.applyInvocation(ServerRpcMethodInvocation) line: 158    
ServerRpcManager<T>.applyInvocation(ClientConnector, ServerRpcMethodInvocation) line: 119    
ServerRpcHandler.handleInvocation(UI, ClientConnector, ServerRpcMethodInvocation) line: 437    
ServerRpcHandler.handleInvocations(UI, int, JsonArray) line: 402    
ServerRpcHandler.handleRpc(UI, Reader, VaadinRequest) line: 273    
UidlRequestHandler.synchronizedHandleRequest(VaadinSession, VaadinRequest, VaadinResponse) line: 90    
UidlRequestHandler(SynchronizedRequestHandler).handleRequest(VaadinSession, VaadinRequest, VaadinResponse) line: 41    
VaadinServletService(VaadinService).handleRequest(VaadinRequest, VaadinResponse) line: 1435    
WmsServlet(VaadinServlet).service(HttpServletRequest, HttpServletResponse) line: 380    
WmsServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 790    
ServletHolder.handle(Request, ServletRequest, ServletResponse) line: 769    
ServletHandler$CachedChain.doFilter(ServletRequest, ServletResponse) line: 1667    
WebSocketUpgradeFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 172    
ServletHandler$CachedChain.doFilter(ServletRequest, ServletResponse) line: 1650    
ServletHandler.doHandle(String, Request, HttpServletRequest, HttpServletResponse) line: 583    
ServletHandler(ScopedHandler).handle(String, Request, HttpServletRequest, HttpServletResponse) line: 143    
ConstraintSecurityHandler(SecurityHandler).handle(String, Request, HttpServletRequest, HttpServletResponse) line: 577    
SessionHandler.doHandle(String, Request, HttpServletRequest, HttpServletResponse) line: 223    
JettyWebAppContext(ContextHandler).doHandle(String, Request, HttpServletRequest, HttpServletResponse) line: 1125    
ServletHandler.doScope(String, Request, HttpServletRequest, HttpServletResponse) line: 515    
SessionHandler.doScope(String, Request, HttpServletRequest, HttpServletResponse) line: 185    
JettyWebAppContext(ContextHandler).doScope(String, Request, HttpServletRequest, HttpServletResponse) line: 1059    
JettyWebAppContext(ScopedHandler).handle(String, Request, HttpServletRequest, HttpServletResponse) line: 141    
ContextHandlerCollection.handle(String, Request, HttpServletRequest, HttpServletResponse) line: 215    
HandlerCollection.handle(String, Request, HttpServletRequest, HttpServletResponse) line: 110    
JettyServer(HandlerWrapper).handle(String, Request, HttpServletRequest, HttpServletResponse) line: 97    
JettyServer(Server).handle(HttpChannel<?>) line: 497    
HttpConnection$HttpChannelOverHttp(HttpChannel<T>).handle() line: 311    
HttpConnection.onFillable() line: 248    
AbstractConnection$ line: 540    
QueuedThreadPool.runJob(Runnable) line: 610    
QueuedThreadPool$ line: 539 line: 745    

I see the new values here, they just never get sent to the non-editable grid line ( editor is closed at this point ). If I double click the same line again, the form fields look perfect, having my new values.

Ok, I just noticed something interesting. For the Grid that works, the sequence of events is as follows:

  1. Call getter, getting old values ( startTransaction in field group, it looks like )
  2. Call setter, setting new values
  3. Call getter, getting new value ( this time ultimately called from RpcDataProviderExtension method internalUpdateRows, using RowDataGenerator method generateData and the methods it calls )
  4. Call getter, getting new values ( from discard, as above )

So I guess the “discard” might be ok? Maybe the problem is that something in my setup is not triggering RowDataGenerator??

So is the missing call to internalUpdateRows causing a problem? Why would it not be called?

Ok, as per
, I solved the buffered mode problem by calling grid.setContainerDataSource. Obviously, the unbuffered mode still does not work. Not really sure. If my customers complain, I will repost that issue separately, but I did want to tell people how I sort of solved this issue, in case it helps them.