Lets say I have worksheet 1 tied to datas source A & worksheet 2 tied to data source B. I have a parameter called ParmABC in both data source A & B. In a dashboard, I have include worksheet 1 & worksheet 2. I want to enter the value once for ParmABC & have the value applied to both data sources. How can I do this?
Design options:
1) Make parameters data source independent. Currently our parameters are tied to a specific data source. If they were data source independent, then this wouldn't be an issue.
2) Similar to sharing filters concept, introduce a shared parameter concept
3) On a dashboard, have a way to link the parameters together.
We will go with this approach.
425 KB
22 KB
541 KB
Progress:
Exploring updating parameters across dataSources. Since the parameters are only modified in a small number of places, we can write methods to extend this update across datasources. For example, say we limit "sharing" to parameters of the same name on different datasources (use case by customer). We can iterate through datasources and modifyParameterField according to the new values. Running through initial test cases to find obvious problems trouble spots for strategy.
Enforcing the "same name" means we can leverage all the existing name limits for parameters (error messaging, etc).
UI: If we include a checkbox that allows user to choose Shared or Make Parameter Global, etc we can track this when we modify the parameter. We'll need to check isShared and make sure the active fieldmanager is not included in the update, since the existing modifyParameter handles that.
It might also be useful to render the name in italics or something similar to remind the user that a given parameter is shared across data sources.
Next step: Can we handle all the changes via worksheetPane/fieldEvent?
Progress:
Tracking fieldEvents for nameChange, valueChange, format, dataType, etc to follow patterns for Sharing Parameter changes.
Value changes including undo/redo working in quick prototype, so can expand strategy to fieldEvents / other parameterData changes (after design discussion, etc).
Progress:
Tracking fieldEvents for nameChange, valueChange, format, dataType, etc to follow patterns for Sharing Parameter changes.
Value changes including undo/redo working in quick prototype, so can expand strategy to fieldEvents / other parameterData changes (after design discussion, etc).
Progress: Testing discussed with Sachin re: parameter field names and data refresh.
1) Parameter cannot share name with existing field, paramterField or otherwise. If User attempts to rename/create parameter with existing name, standard "field already exists" error message is given.
2) If field is renamed in datasource to existing ParameterField name, it will be appended with "1" on data refresh. This is same behavior for any field renamed in datasource with duplicate name. Column name can be shared, but field name is changed to prevent duplicates.
Progress: Testing discussed with Sachin re: parameter field names and data refresh.
1) Parameter cannot share name with existing field, paramterField or otherwise. If User attempts to rename/create parameter with existing name, standard "field already exists" error message is given.
2) If field is renamed in datasource to existing ParameterField name, it will be appended with "1" on data refresh. This is same behavior for any field renamed in datasource with duplicate name. Column name can be shared, but field name is changed to prevent duplicates.
Options 1 and 2 are large in scope. We should go with a modified option 3 as follows:
Options 1 and 2 are large in scope. We should go with a modified option 3 as follows:
Please make the following changes:
The following scenarios require fixing:
Scenario 1:
Scenario 2:
Scenario 3:
Please make the following changes:
The following scenarios require fixing:
Scenario 1:
Scenario 2:
Scenario 3:
SVN #56215 addresses the "Please make the following changes" section in this comment. However the remaining 3 scenarios are still not fixed. Additionally, the following scenario is observed:
SVN #56215 addresses the "Please make the following changes" section in this comment. However the remaining 3 scenarios are still not fixed. Additionally, the following scenario is observed:
revision #56224
Changes: LinkParameterListener and UnlinkParameterListener are now separate classes. ParameterControlPanel and ParameterDashboardItem menu's now have an option to link/unlink the parameters.
revision #56226
Changes: Support proper editing support of existing linked parameters. This is required so that the value from the editing of one value could be propagated as the value to the others
revision #56227
Changes: Missed these two files in the last commit. Are required in the last commit.
revision #56224
Changes: LinkParameterListener and UnlinkParameterListener are now separate classes. ParameterControlPanel and ParameterDashboardItem menu's now have an option to link/unlink the parameters.
revision #56226
Changes: Support proper editing support of existing linked parameters. This is required so that the value from the editing of one value could be propagated as the value to the others
revision #56227
Changes: Missed these two files in the last commit. Are required in the last commit.
Scenario 1:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:657) at java.util.ArrayList.get(ArrayList.java:433) at com.aquafold.bistudio.sheet.BISheetWorksheetPane.handleFieldChanges(BISheetWorksheetPane.java:568) at com.aquafold.bistudio.sheet.BISheetsPane.handleFieldChanges(BISheetsPane.java:907) at com.aquafold.bistudio.event.BIFieldListenerQueue.notify(BIFieldListenerQueue.java:29) at com.aquafold.bistudio.BIStudio.notifyFieldListener(BIStudio.java:1832) at com.aquafold.bistudio.BIStudio.notifyFieldChanges(BIStudio.java:1821) at com.aquafold.bistudio.model.BIFieldManager.fireFieldEvent(BIFieldManager.java:1947) at com.aquafold.bistudio.model.BIFieldManager.runBatch(BIFieldManager.java:4081) at com.aquafold.bistudio.model.BIFieldManager.renameDataField(BIFieldManager.java:3783) at com.aquafold.bistudio.model.BIFieldManager.renameDataSourceField(BIFieldManager.java:973) at com.aquafold.bistudio.model.BIFieldManager.renameDataSourceField(BIFieldManager.java:939) at com.aquafold.bistudio.rename.RenameFieldDialog.execute(RenameFieldDialog.java:271) at com.aquafold.bistudio.rename.RenameFieldDialog.onRename(RenameFieldDialog.java:110) at com.aquafold.bistudio.rename.RenameFieldDialog$3.actionPerformed(RenameFieldDialog.java:105) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:376) at javax.swing.plaf.basic.BasicRootPaneUI$Actions.actionPerformed(BasicRootPaneUI.java:208) at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1663) at javax.swing.JComponent.processKeyBinding(JComponent.java:2882) ...
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
Scenario 6:
Scenario 1:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:657) at java.util.ArrayList.get(ArrayList.java:433) at com.aquafold.bistudio.sheet.BISheetWorksheetPane.handleFieldChanges(BISheetWorksheetPane.java:568) at com.aquafold.bistudio.sheet.BISheetsPane.handleFieldChanges(BISheetsPane.java:907) at com.aquafold.bistudio.event.BIFieldListenerQueue.notify(BIFieldListenerQueue.java:29) at com.aquafold.bistudio.BIStudio.notifyFieldListener(BIStudio.java:1832) at com.aquafold.bistudio.BIStudio.notifyFieldChanges(BIStudio.java:1821) at com.aquafold.bistudio.model.BIFieldManager.fireFieldEvent(BIFieldManager.java:1947) at com.aquafold.bistudio.model.BIFieldManager.runBatch(BIFieldManager.java:4081) at com.aquafold.bistudio.model.BIFieldManager.renameDataField(BIFieldManager.java:3783) at com.aquafold.bistudio.model.BIFieldManager.renameDataSourceField(BIFieldManager.java:973) at com.aquafold.bistudio.model.BIFieldManager.renameDataSourceField(BIFieldManager.java:939) at com.aquafold.bistudio.rename.RenameFieldDialog.execute(RenameFieldDialog.java:271) at com.aquafold.bistudio.rename.RenameFieldDialog.onRename(RenameFieldDialog.java:110) at com.aquafold.bistudio.rename.RenameFieldDialog$3.actionPerformed(RenameFieldDialog.java:105) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:376) at javax.swing.plaf.basic.BasicRootPaneUI$Actions.actionPerformed(BasicRootPaneUI.java:208) at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1663) at javax.swing.JComponent.processKeyBinding(JComponent.java:2882) ...
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
Scenario 6:
Revision #56241
Scenario 4 mentioned above is partially fixed since only the dataSource to which the parameter is associated is refreshed. This results in updating only the worksheet or chart where this datasource is marked as the primary datasource.
Revision #56241
Scenario 4 mentioned above is partially fixed since only the dataSource to which the parameter is associated is refreshed. This results in updating only the worksheet or chart where this datasource is marked as the primary datasource.
Revision #56244
Corrected a failing check for linked parameter propagation, which leads to a hung ChartPanel wherein "Computing Visualization" is observed.
Revision #56244
Corrected a failing check for linked parameter propagation, which leads to a hung ChartPanel wherein "Computing Visualization" is observed.
In SVN rev 56248, I've fixed the existing bug where updating a parameter value in dashboard is not reflected in the chart unless the parameter belongs to the last selected worksheet. However following scenario as noted before is still observed:
The root cause is that ParameterColumn.setValue(newValue) is being invoked only for the parameter field corresponding to the parameter control. The same method is not invoked for the linked parameters in other datasources. This method must be invoked for each linked datasource in order for the chart using the datasource to observe the new parameter value.
Also, the use of "isLinked" in BISheetworksheetPane is incorrect. It will cause more rebuilding of worksheets than necessary. For example, if I change the value of a linked parameter, it will cause all datasources to get rebuilt, even those that the parameter is not linked with. Instead it should rebuild/refresh only the linked datasources, for example using similar logic as in line 1830 of BISheetworksheetPane.
In SVN rev 56248, I've fixed the existing bug where updating a parameter value in dashboard is not reflected in the chart unless the parameter belongs to the last selected worksheet. However following scenario as noted before is still observed:
The root cause is that ParameterColumn.setValue(newValue) is being invoked only for the parameter field corresponding to the parameter control. The same method is not invoked for the linked parameters in other datasources. This method must be invoked for each linked datasource in order for the chart using the datasource to observe the new parameter value.
Also, the use of "isLinked" in BISheetworksheetPane is incorrect. It will cause more rebuilding of worksheets than necessary. For example, if I change the value of a linked parameter, it will cause all datasources to get rebuilt, even those that the parameter is not linked with. Instead it should rebuild/refresh only the linked datasources, for example using similar logic as in line 1830 of BISheetworksheetPane.
Revision #56252
Hi Nhi,
Thanks for fixing the known issue. Following are the new changes.
Revision #56252
Hi Nhi,
Thanks for fixing the known issue. Following are the new changes.
Revision #56253
Accidentally reverted a change in last commit which was committed by Nhi to solve an existing issue.
Revision #56253
Accidentally reverted a change in last commit which was committed by Nhi to solve an existing issue.
The change of approach in SVN #56252 is incorrect. The notification infrastructure for handling datasource changes may be complicated, but it was necessary due to the nature of how VA works. In VA, data queries and model calculations can be time consuming, so they are handled in background threads to avoid locking up the GUI. This introduces contentions between foreground (GUI) and background threads, and thus a lot of safeguards had to be put in place to handle this delicate nature. Thus the handling of parameter changes (which is a type of datasource change) must be done via the existing notification infrastructure. And this is the reason why long delays are observed in the parameter operations after SVN #56252. Perhaps it may be possible to use direct handling of datasource changes rather than the notification machanism, but that will be a HUGE effort, not something that can fit in the timeframe of this project.
Please revert the code changes and use another approach to fix the scenario observed in this comment.
The change of approach in SVN #56252 is incorrect. The notification infrastructure for handling datasource changes may be complicated, but it was necessary due to the nature of how VA works. In VA, data queries and model calculations can be time consuming, so they are handled in background threads to avoid locking up the GUI. This introduces contentions between foreground (GUI) and background threads, and thus a lot of safeguards had to be put in place to handle this delicate nature. Thus the handling of parameter changes (which is a type of datasource change) must be done via the existing notification infrastructure. And this is the reason why long delays are observed in the parameter operations after SVN #56252. Perhaps it may be possible to use direct handling of datasource changes rather than the notification machanism, but that will be a HUGE effort, not something that can fit in the timeframe of this project.
Please revert the code changes and use another approach to fix the scenario observed in this comment.
As I mentioned in the call.
Found an existing issue while editing and undo parameter value.
Scenario
1. open VA link-param.vizx
2. go to the dashboard
3. Change parameter1 value to 30 of worksheet 3.
4. click Undo.
5. Parameter1 of worksheet 2 got changed while parameter1 of worksheet 3 remain unchanged
(Which is incorrect)
Thanks
Pankaj
As I mentioned in the call.
Found an existing issue while editing and undo parameter value.
Scenario
1. open VA link-param.vizx
2. go to the dashboard
3. Change parameter1 value to 30 of worksheet 3.
4. click Undo.
5. Parameter1 of worksheet 2 got changed while parameter1 of worksheet 3 remain unchanged
(Which is incorrect)
Thanks
Pankaj
Revision #56264
Changes:
Revision #56264
Changes:
Scenario 1:
Scenario 1:
Hi Nhi,
Actually, this problem is introduced after Revision #56248 where the dataSource is selected from the event rather than the default one. I reverted your changes locally and then was not able to reproduce it. Could you please have a look into it.
Hi Nhi,
Actually, this problem is introduced after Revision #56248 where the dataSource is selected from the event rather than the default one. I reverted your changes locally and then was not able to reproduce it. Could you please have a look into it.
All the above scenarios other than the last scenario are working fine as expected.
As Hussain has already cleared that due to Revision #56248 last scenario is getting reproduced.
Nhi, Please confirm whether I should mark it verified?
All the above scenarios other than the last scenario are working fine as expected.
As Hussain has already cleared that due to Revision #56248 last scenario is getting reproduced.
Nhi, Please confirm whether I should mark it verified?
In SVN #56274 I've fixed the last scenario here.
However the following scenarios are still broken:
In SVN #56274 I've fixed the last scenario here.
However the following scenarios are still broken:
Hi Nhi,
The above scenario is fixed. I also fixed some issues related to undo redo operations.
While testing above scenario, I observed one existing issue which is also fixed in below change set.
The issue was,
1. Open link-params.vizx in VA, goto Dashboard
2. Try to Edit Parameter1 for first sheet using Edit Parameter dialog
3. Result: The value is not updated in Parameter1 field
4. Expected: The value should be updated in Parameter1 field
Same problem is with Parameter1 for second sheet. When try to edit Parameter1 for third sheet using Edit parameter dialog then "A field named 'Parameter1' already exists" error occurs in the Edit Parameter dialog.
Root Cause:
In the ParameterFieldDialog class, at the line no. 374 (in the latest change), the fieldManager instance is extracted from _parentWindow.getSelectedDataSource()
Fix:
I am getting fieldManager instance from _field.getDataSource()
Please have a look
Hi Nhi,
The above scenario is fixed. I also fixed some issues related to undo redo operations.
While testing above scenario, I observed one existing issue which is also fixed in below change set.
The issue was,
1. Open link-params.vizx in VA, goto Dashboard
2. Try to Edit Parameter1 for first sheet using Edit Parameter dialog
3. Result: The value is not updated in Parameter1 field
4. Expected: The value should be updated in Parameter1 field
Same problem is with Parameter1 for second sheet. When try to edit Parameter1 for third sheet using Edit parameter dialog then "A field named 'Parameter1' already exists" error occurs in the Edit Parameter dialog.
Root Cause:
In the ParameterFieldDialog class, at the line no. 374 (in the latest change), the fieldManager instance is extracted from _parentWindow.getSelectedDataSource()
Fix:
I am getting fieldManager instance from _field.getDataSource()
Please have a look
Scenario 1:
Scenario 1:
Hi Nhi,
I fixed above scenario as well as some other undo scenarios. Please have a look.
Hi Nhi,
I fixed above scenario as well as some other undo scenarios. Please have a look.
The following scenario is a new breakage in Dev-63.
Scenario 1:
The following scenario is a new breakage in Dev-63.
Scenario 1:
Looks good.
@QA: Please retest all past scenarios.
Looks good.
@QA: Please retest all past scenarios.
Hi,
All the above scenarios are working fine as per the expectations on ADS19.5.0-dev-65 build. Hence marking it as Verified.
Hi,
All the above scenarios are working fine as per the expectations on ADS19.5.0-dev-65 build. Hence marking it as Verified.
Issue #14821 |
Verified |
Fixed |
Resolved |
Completion |
No due date |
Fixed Build ADS19.5.0-dev-65 |
No time estimate |
Progress:
Exploring updating parameters across dataSources. Since the parameters are only modified in a small number of places, we can write methods to extend this update across datasources. For example, say we limit "sharing" to parameters of the same name on different datasources (use case by customer). We can iterate through datasources and modifyParameterField according to the new values. Running through initial test cases to find obvious problems trouble spots for strategy.
Enforcing the "same name" means we can leverage all the existing name limits for parameters (error messaging, etc).
UI: If we include a checkbox that allows user to choose Shared or Make Parameter Global, etc we can track this when we modify the parameter. We'll need to check isShared and make sure the active fieldmanager is not included in the update, since the existing modifyParameter handles that.
It might also be useful to render the name in italics or something similar to remind the user that a given parameter is shared across data sources.
Next step: Can we handle all the changes via worksheetPane/fieldEvent?