Elasticube Build Behaviour - Upsert
Currently, the "Upsert" build behavior is only available for Build to destination. It would be great if we were able to utilize this feature in our Elasticube model where we are not building to destination. We have numerous tables containing created date as well as updated date that are attached to an id field but are unable to use the updated date field since this will bring in duplicate (or more) rows per id which we can not have. Ranking duplicates and filtering out is not a sustainable with the size of our datasets. The ability to look at the id and updated field would solve this issue without the need for a complex workaround in our data source (Big Query). Thank you!
Enable dynamic datasets (databases) for BigQuery
Currently, dynamic/parameterized datasets are not supported in BigQuery connections. You can parameterize the service account information, which is great, but it would be helpful to be able to use a parameter to swap the dataset in the BigQuery connection based on who's currently viewing the dashboard. For reference, parameterized datasets and schemas are supported by other database engines: Azure Synapse MS SQL MySQL PostgreSQL Redshift Snowflake
Here are some improvements looking for better usability
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 JReusable/shared connection information for data models
It seems strange to me that each time I need to add another table to my model, I have to re-enter all the connection (or pick a recent connection). If i have 10 tables in my model, they all have their own individual connection information. If a server name ever gets renamed, it'll be a crazy headache for us. There should be a place where you define the distinct list of actual database connections (one per server or database), give it a name, apply security, etc. And then when you go to add a table to a data model, at that point you pick from the previously defined available list of connections.Email Report Format - Add Excel support
For users who wish to receive their Dashboard contents using the Subscription service, Sisense supports embedded emails or PDF format only. For convenience and expedience, I would like to see support for users to receive compatible Dashboards (e.g. Pivot Tables) directly as an Excel attachment. This will help for users who wish to receive regular emails containing important data in Excel format for integration with other systems.Connection Tool - Programmatically Remove Unused Datasource Connections, and List All Connections
Managing connections within your Sisense environment can become complex over time, if there are a large number of connections, and connections are often added, and replace earlier datasource connections. In some scenarios unused connections can accumulate, potentially cluttering the connection manager UI with no longer relevant connections. Although unused connections typically represent minimal direct security risk, it's considered best practice to maintain a clean, organized list of connections, and in some scenarios it can be desired to remove all unused connections. Sisense prevents the deletion of connections actively used in datasources, safeguarding your dashboards and datasources from disruptions. However, inactive or "orphaned" connections remain after datasources are deleted or a connection is replaced, potentially contributing to unnecessary UI complexity in the connection manager UI. Connections can be of any type Sisense supports, common types include various SQL connections, Excel files, and CSV files, as well as many data providers, such as Big Panda. This tool can also be used to list all connections, with no automatic deletion of unused connections.Different database connections on staging server vs production server
Hi, We have two cloud servers in Sisense: one for development (staging) and one for production. The staging server connects to our staging database. The production server connects to our production database. All cubes and dashboards are identical except for database connection strings and names. Our Git branching strategy follows these steps: Create a feature branch from staging. Make changes and push them to the feature branch. Open a pull request from the feature branch to staging. Test changes in staging. If approved, merge staging into master (production) to deploy changes. The Issue Git integration tracks database connection names, meaning both servers must either run on staging data or production data—this is not feasible for us. Proposed Solution We suggest implementing a decentralized environmental variable for storing database connections. For example: Use {database-server-name} as a placeholder in configurations. Set database-server-name = db_server_staging on staging. Set database-server-name = db_server_production on production. This would allow the same codebase to dynamically connect to the appropriate database without manual adjustments. Would love to hear your thoughts on this!Refresh Schema via API
We are trying to investigate how we can trigger a Sisense data model (schema) refresh from the API. This call would be made after a data pipeline schema change. We’ll need the calls to make to "Refresh Schema" how it is done in the UI. Original Community Post by haarishussain : https://community.sisense.com/t5/help-and-how-to/sisense-api-model-refresh/td-p/21719
