Flexmonster object becomes null on runQuery() API call in version 2.8.4

Hi Vaibhav,
 
Thank you for posting your question.
 
We've run some tests on both versions 2.7.18 & 2.8.2 and we haven't managed to reproduce the issue with either version. Still, we would suggest updating to the latest version 2.8.4 and see if the issue persists after the update.
 
Alternatively, it would also be helpful if you could share your report sample together with the runQuery() configurations you're using so that we can investigate this further.
 
Thank you in advance and looking forward to your response.
 
Best regards,
Mykhailo

Hi Vaibhav,
 
Thank you for the clarification!
 
In this case, it would really help us to have a sample of your data and report configurations, as well as the slice object you are passing to the runQuery() API call. Would it be possible for you to provide us with this information?
 
Alternatively, you can also modify the following JSFiddle sample for the runQuery() API call and send it back to us with the configurations with which the issue is reproducible: https://jsfiddle.net/flexmonster/4nhov6z7/
 
Looking forward to hearing from you.
 
Best regards,
Mykhailo

Hi Vaibhav,
 
My apologies for the slightly delayed response.
 
We've run some further tests with the runQuery() API call applying configurations which could be considered unsuitable in this situation, but we still did not manage to get the pivot table instance disposed.
 
We fully understand that it might not be possible to provide your actual data due to security concerns. At the same time, instead of the actual data, would it be possible for you to prepare some kind of dummy data with the same structure? This way, there will be a higher chance of us reproducing the issue and you won't have to worry about your data being exposed.
 
In case you still have security concerns, you can also send the dummy data set to us via an email.
 
Please let us know what you think. 
 
Best regards,
Mykhailo

Hi Vaibhav,
 
Thank you for reporting this behavior.
 
This issue has previously been reported and we are going to provide the fix as a part of the upcoming minor release ETA May 18th. To resolve this, we will make sure that the columns in the input CSV are matched with those in the Mapping object by column names instead of indexes.
 
Please let us know if you have any other questions we can help you with in the meantime. 
 
Best regards
Mykhailo

Hi Vaibhav,
 
We are happy to let you know that mapping for CSV is now applied by column names instead of column indexes. Moreover, it is now applied on top of the default structure, meaning that it does not require to enumerate all fields.
 
This is provided in the 2.8.7 version of Flexmonster: https://www.flexmonster.com/release-notes/
You are welcome to update the component. Here is our updating to the latest version tutorial for guidance: https://www.flexmonster.com/doc/updating-to-the-latest-version/ 
 
Please contact us in case any questions arise.
 
Best regards,
Mykhailo

Hi Vaibhav,
 
Thank you for writing to us.
 
We've double-checked this on our side and didn't manage to reproduce any issues neither with the runQuery() API call nor with CSV mapping in general with version 2.8.7.
 
We would suggest starting with clearing your browser's cache to ensure that the latest Flexmonster version has been loaded properly. If this does not help, it would greatly speed up our investigation of this issue if you could provide us with your report sample together with the runQuery() configurations you're trying to use.
 
Answering your last question, when using CSV as your data source, you now don't have to specify all of the fields in the Mapping object – those that weren't defined in the mapping will employ their own structure defined for all fields by default. This behavior is different from that of JSON, for example, where once one field was specified in the Mapping object, all other hierarchies have to be defined there as well in order for them to be available in the Field list.
 
Looking forward to your reply.
 
Regards,
Mykhailo

Hi Vaibhav,
 
Thank you for your fast response.
 
We did manage to reproduce the described behavior thanks to the provided CSV sample and your mapping configurations.
 
After a little bit of research, we've realized that the issue lies in the mapping for CSV – more specifically, the fields of the hidden type cause the mentioned console error. We are going to investigate this further and return with a fix ETA Jun 15th.
 
However, to avoid this behavior earlier, we would suggest using the visible property of the Mapping object – when set to false, it hides the corresponding field the same way the hidden property does. More on this here: https://www.flexmonster.com/api/mapping-object/
 
We've already tested visible on our side with your configurations and everything seems to be working correctly.
 
Please let us know if this helps.
 
Regards,
Mykhailo

Hi Vaibhav,
 
Thank you for your fast response.
 
We'll make sure to investigate this in the nearest future and return to you once we have any updates.
 
Kind regards,
Mykhailo

Hi Vaibhav,
 
We are glad to announce that the issue with hidden fields in mapping breaking the report with CSV data source was fixed. The hidden property now works as expected.
 
This is included in the 2.8.8 version of Flexmonster: https://www.flexmonster.com/release-notes/. You are welcome to update the component: https://www.flexmonster.com/doc/updating-to-the-latest-version/
 
However, we would also suggest reconsidering using the visible property instead – while providing the same functionality as the hidden option, it is a more recommended approach and is actually available for the CSV data source as well (we've already fixed this inconsistency in our documentation). Please see the following JSFiddle sample for illustration: https://jsfiddle.net/flexmonster/br6nfudk/
 
Feel free to write to us in case of questions.
 
Best regards,
Mykhailo

Hi Vaibhav,
 
How are you?
 
We were wondering if the last update helped you solve the mentioned issue. Was it resolved, or does it still persist?
 
We would be happy to hear your feedback.
 
Regards,
Mykhailo