This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

Problems with pivot table

General questions regarding the development with JVx.

Problems with pivot table

Postby Davidge » Wed Nov 18, 2020 4:16 pm

Hi,

I've problem with a pivot query. When the count of pivot columns changes and I reopen my workscreen, I get this error message. Is it possible to clear the meta data of my local RemoteDataBook?

Code: Select all
P1: BAS-99999: javax.rad.model.ModelException: Remote storage returned 7 value(s) but 8 were expected (check meta data)!
   at com.sibvisions.rad.model.remote.RemoteDataPage.fetchToRow(RemoteDataPage.java:213)
   at com.sibvisions.rad.model.mem.MemDataPage.getDataRowStorage(MemDataPage.java:547)
   at com.sibvisions.rad.model.mem.MemDataBook.setSelectedRowInternal(MemDataBook.java:5912)
   at com.sibvisions.rad.model.mem.MemDataBook.correctSelectedRow(MemDataBook.java:5670)
   at com.sibvisions.rad.model.mem.MemDataBook.sync(MemDataBook.java:5740)
   at com.sibvisions.rad.model.mem.MemDataBook.getSelectedDataPageRow(MemDataBook.java:1983)
   at com.sibvisions.rad.model.mem.MemDataBook.getSelectedRow(MemDataBook.java:1409)
   at com.sibvisions.apps.components.NavigationTable.doEnableButtons(NavigationTable.java:1575)
   at com.sibvisions.apps.components.NavigationTable.beforeAddNotify(NavigationTable.java:447)
   at javax.rad.genui.UIContainer.beforeAddNotify(UIContainer.java:251)
   at javax.rad.genui.UIContainer.beforeAddNotify(UIContainer.java:251)
   at javax.rad.genui.UIContainer.beforeAddNotify(UIContainer.java:251)
   at javax.rad.genui.UIContainer.beforeAddNotify(UIContainer.java:251)
   at javax.rad.genui.UIContainer.beforeAddNotify(UIContainer.java:251)
   at com.sibvisions.apps.projx.screens.DataSourceWorkScreen.beforeAddNotify(DataSourceWorkScreen.java:326)
   at javax.rad.genui.UIContainer.addInternal(UIContainer.java:497)
   at javax.rad.genui.UIContainer.add(UIContainer.java:141)
   at javax.rad.genui.UIContainer.add(UIContainer.java:123)
   at com.sibvisions.apps.projx.InternalFrameWorkScreenManager.createContainer(InternalFrameWorkScreenManager.java:159)
   at de.grass.apps.coago.GrassWorkScreenManager.createContainer(GrassWorkScreenManager.java:27)
   at com.sibvisions.apps.projx.ProjX.openWorkScreen(ProjX.java:2196)
   at de.grass.apps.coago.GrassApplication.openWorkScreen(GrassApplication.java:1594)
   at com.sibvisions.apps.projx.ProjX.openWorkScreen(ProjX.java:878)
   at de.grass.apps.coago.util.pgm.AbstractPgmCommandModuleCall.doModuleCall(AbstractPgmCommandModuleCall.java:141)
   at de.grass.apps.coago.util.pgm.AbstractPgmCommandModuleCall.doAfterSetPgmData(AbstractPgmCommandModuleCall.java:170)
   at de.grass.apps.coago.util.pgm.AbstractPgmCommandModuleCall.executeLoc(AbstractPgmCommandModuleCall.java:95)
   at de.grass.apps.coago.util.pgm.PgmCommandCF.executeLoc(PgmCommandCF.java:37)
   at de.grass.apps.coago.util.pgm.AbstractPgmCommandModuleCall.lambda$executeWithAsk4Commit$0(AbstractPgmCommandModuleCall.java:62)
   at de.grass.apps.coago.util.InvokeUtil.lambda$invokeInUI$9(InvokeUtil.java:139)
   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
   at java.awt.EventQueue.access$500(EventQueue.java:97)
   at java.awt.EventQueue$3.run(EventQueue.java:709)
   at java.awt.EventQueue$3.run(EventQueue.java:703)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Davidge
 
Posts: 8
Joined: Fri Aug 28, 2020 4:28 pm

Re: Problems with pivot table

Postby Support@SIB » Mon Nov 23, 2020 2:11 pm

Did you try:

Code: Select all
remoteDataBook.setMetaDataCacheEnabled(false);

This code is for client-side metadata caching. It's also possible to clear the client-side metadata via

Code: Select all
RemoteDataSource.clearGlobalMetaData(screenConnection)

This call will clear the metadata of one screen.

On server-side, call:

Code: Select all
AbstractCachedStorage.removeMetaData(SessionContext.getCurrentSession().getLifeCycleName());

to remove the cache per lifecycle object. It's also possible to clear the cache per application name, but above methods will help you.
User avatar
Support@SIB
 
Posts: 349
Joined: Mon Sep 28, 2009 1:56 pm

Re: Problems with pivot table

Postby Davidge » Tue Nov 24, 2020 11:04 am

Hi,

this works for a close and new reopen of my workscreen. But when data is changed in the background and I do a refresh in my workscreen, I'll get the same error! It seems that the server side clear does work but the client will not get the effect.
Davidge
 
Posts: 8
Joined: Fri Aug 28, 2020 4:28 pm

Re: Problems with pivot table

Postby Support@SIB » Tue Nov 24, 2020 11:52 am

Clear, because the databook is still open and has old metadata, e.g. 2 columns. The metadata are required for the table columns, ... And as long as the databook is open, the same metadata will be used.

If you change the column list because the server-side storage has changed - which may be confusing for the user - you have to notify the databook. Also, if you don't change the number of columns but the column order, it's also the same!

This is a general development problem and not related to the framework :!:

You could close/open the databook in case of reload?
User avatar
Support@SIB
 
Posts: 349
Joined: Mon Sep 28, 2009 1:56 pm

Re: Problems with pivot table

Postby Davidge » Fri Nov 27, 2020 9:26 am

No, it is not a general development problem but is related to the framework. Why should a user be confused when server data changes. A user is not responsible for the databook. A user just want it to work correctly. So when a user expects a pivot table, where columns can change dynamically, and the columns changes on the server I await the correct behaviour on my client.

We are using now a other workaround at the moment but this is definitely a bug.
Davidge
 
Posts: 8
Joined: Fri Aug 28, 2020 4:28 pm

Re: Problems with pivot table

Postby Development@SIB » Fri Nov 27, 2020 10:01 am

Sorry, but this is not a bug.

If you use plain JDBC and select a list of columns, this is comparable. If your db model change because you remove a column, your statement will fail until you change it.

In JVx case, you open the databook and until you close it, everything is "fixed". If you close and open it again, the new information is retrieved - for example if you close/open the screen. A simple reload should update the current records and not the whole screen - but this is screen specific and can be use-case related.

Yes, JVx has some caches and if you use them, things might be different, but this is also if you cache your plain JDBC result sets. So, you disabled caching for your screen, and everything is fine so far.

So, a bug is something what's implemented and doesn't work as expected. In case of our data book, the exception is expected and there is code for exact this use-case. We can discuss if there's a better solution, but till now we didn't find a better implementation which covers all possible use-cases.

If you change the server-side without telling the client that something has changed, it's good to see the problem. If we don't check metadata and simply update it, what should happen if you bind an editor to a column which is not available? Currently the editor is disabled and red... But the GUI is not working as developed - right?

Our definition of a bug is not: It doesn't work as I want that it should work.

And, JVx preferred storage usage is "create once" and re-use it until you close it. In your case, you use JVx for generic queries - which is well supported. But don't expect magic if you do what you think. And yes, JVx doesn't solve all common development problems.

And we guess that you have some performance problem with the pivot table? Not sure, it's an assumption, but maybe...

If you create the storage on every access, you don't have something like that:

Code: Select all
public DBStorage getOfferarticle() throws Exception
{
   DBStorage dbsOfferarticle = (DBStorage)get("offerarticle");
   if (dbsOfferarticle == null)
   {
      dbsOfferarticle = new DBStorage();
      dbsOfferarticle.setWritebackTable("offerarticle");
      dbsOfferarticle.setDBAccess(getDBAccess());
      dbsOfferarticle.open();

      put("offerarticle", dbsOfferarticle);
   }
   return dbsOfferarticle;
}

Your code might look like:

Code: Select all
public DBStorage getOfferarticle() throws Exception
{
   DBStorage dbsOfferarticle = new DBStorage();
   dbsOfferarticle.setWritebackTable("offerarticle");
   dbsOfferarticle.setDBAccess(getDBAccess());
   dbsOfferarticle.open();

   return dbsOfferarticle;
}


This will do many db requests again and again - not necessarily, e.g. if you filter/search, sort, export -> always a new storage...
There's a better solution for such problems. But again, it's an assumption.
User avatar
Development@SIB
 
Posts: 325
Joined: Mon Sep 28, 2009 1:54 pm


Return to Development