Sometimes when you use large mapping tables, or using mapping tables inside a loop it would be good if the mapping table could be dropped. There is no reason to keep a huge mapping table in memory if is not to be used anymore (i do know mapping tables are dropped at the end of script execution).
So my suggestion is one of the following;
* Enable drop of mapping table with the Drop Table(s) cmd;
* Create a new Drop Mapping Table(s) statement
I initially thought that UnMap could be used to drop mapping tables but that one only works on fields names used for map.. using
Thank you for your feedback on ways to improve our product. While this is something we understand would be useful, it's not on the short-term roadmap. Please continue to show your support for this idea.
I would like to create a mapping-table within a loop witch would be causing trobble now when I cant drop it. It would have been nice to be able to use mappingtables in loops but would require possibility to drop it.
@AronC - when I need to loop through creating non-concatenated tables (including mapping tables), I put a variable into the map name - e.g. something like:
@AlexOmetis that works but is basically a memory leak. Our maps currently have about 4 million rows and we loop 12 times, so we get about 50 million rows in memory and only need 4 of them. We estimate that it wastes something like 60GB of memory during reload. So it strongly limits us how far we can scale, as looping 50 times is just not feasible.
So please: Introduce support to drop mapping tables.
@christopherkramer - yes, we've had the same issue - we ended up reloading the same app multiple times with different loop configuration each time to minimise the number of mapping loads in memory on each run. We found a significant improvement in performance and reduction in memory usage by doing that.
So yes, would be so nice to be able to drop them like you can normal tables.
Allowing dropping of Mapping tables makes sense, this gives control to the developer. And mainly minimises substantial memory leaks, a concept not a lot of QS/QV developers understand. I cringe every time I suspect memory leak in qlik programs/code, as managing memory leaks is something etched into my brain coming from C/C++ background. To be frank Qlik is very poor in managing memory leaks, in the middle of execution itself.
NOTE: Upon clicking this link 2 tabs may open - please feel free to close the one with a login page. If you only see 1 tab with the login page, please try clicking this link first: Authenticate me! then try the link above again. Ensure pop-up blocker is off.
