Product Feedback Forum
Help us make Sisense better by posting your product feedback here.
cancel
Showing results for 
Search instead for 
Did you mean: 
Status: Needs Info

1. View all history of builds and its corresponding logs from the cubes. Because, I could not see the last build failure reason, if another build got started. I need to wait for another build to complete or fail.
2. View all history of changes and provide a way to revert as in Google docs for both the cubes and dashboards. Some times, if something went wrong, we should just be able to revert to the previous version and continue from there.

3. Provide a way to view the list of cubes in the queue waiting for the build. Also, allow remove or disable them for a period or rearrange the queue to build. This will help in prioritizing something manual on demand.


4. If a cube build fails due to the memory or other configurations issue, provide suggestions like what has to be changed and based on what before triggering another build.


5. Provide a page to derive the suggested the configurations like memory, cpu, timeouts etc by collecting details like 1. Number of cubes, 2. average cube size, max cube size, min cube size, or number of cubes by size range say <5g, <10G, <20G, <40G etc.., 3. Frequency of the build per cube etc..


6. Provide a page to view all the slow running dashboards, slow running queries and some suggestions to improve it.

7. Some times, if a dashboard got changed and republished, it is not getting applied to all the users. Provide a way to view the version of the dashboard the user may view.

8. Between builds, if there is not much change in the data, Sisense build should go faster. Provide a way like one common place to build each table from other sources individually and keep it ready. From there, if we build say functional cubes, it should build in flashing fast using the locally stored data. I see the cubes are pulling the data faster from relational db but very slow from mongodb. Now, if we are pulling data from another sisense cube or from the source no big performance difference.

9. Also, I am not sure, if we are restarting the nodes, should we necessarily mark the cubes in queue as failed, instead adding back to the queue as it was before the restart and just marking the actual cube got failed should be good enough.

More later ..

Thanks,

Muthusamy J

1 Comment
Status changed to: Needs Info

Hi @mjayaraman,

I really appreciate all the work you put into this feedback! Would it be possible for you post each suggestion individually? That will allow us to track community interest for each idea and allow people to comment and vote on each one.

Thank you again for your ideas!