Reusable/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.
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!
Add a native connector and dialect for Dremio
We are using Dremio as a universal semantic layer to connect to several backend databases: PostgreSql, Oracle, HDFS, Snowflake. Using the Arraw flight jdbc driver allows the connection to Dremio, but often results in bad queries. I believe a custom dialect will be needed.Create New Sample Data Sets with more data and more concurrent date ranges
Create a new sample data sets that have a lot more data, date ranges that are current to our dates today, has more scenarios that we see in all customers cases. Like more complex formula creations, displaying a wide range of different KPI's, have a more complex data model to show how dimensions and fact tables can work. Having a sample data set with custom code, custom tables, and custom column. Having one of the tables connect to a DW to show how the connection works as well.SingleStore (MemSQL) Connector: Use CONCAT instead of Pipe operator (||)
The queries Sisense generates in some cases uses the pipe operator (||) to concatenate the strings. However, SingleStore has 2 different modes of treating the pipe operator, depending on @@sql_mode engine variable and PIPES_AS_CONCAT flag: flag is ON: pipe operator is treated as CONCAT and the Sisense-generated query works flag is OFF (default): pipe operator is treated as OR and the Sisense-generated query throws an error In order to avoid the ambiguity, I suggest that SingleStore (MemSQL) Connector uses CONCAT instead of pipe operator by default.
Preview table column in query builder
It would very helpful to be able to see the columns of a table in the Table Query section of the MySQL query build. Currently it just list the tables and you have to open another table then preview the table and scroll sideways to see the available column. You could create this in a tree view like SQL Sever does. This would help query writers by being able to see what columns belong to the tables, I included what SQL Server does for reference.
