Hubspot is widely used application for data ingestion and CRM data. I highly suggest that Hubspot become a native JDBC connector within Sisense because it is widely asked for among many users within Sisense. ... View more

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! ... View more

When using Starred Filters, end uses can create their own filter and save the selection for repeat use. However, any Starred Filter created will be visible to all users regardless of their Group or Parameter assignment. This is because these items are stored in the Data Browser as additional elements linked only to the data source and not to a user or group. As a result, this causes confusion, lack of control where one end users Starred Filters can be removed by another and concerns about data security. Appreciate utilising multitenancy would be a solution, however, this is not possible in all circumstances and requires a significant amount of additional administration.  I am recommending a functionality change to control / limit the visibility of Starred Filters to the User or Group that created them.  ... View more

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 ... View more

When editing a cube or live data source, I'd like to be able to more quickly add another table.  Right now, you click on the  +DATA button at the top, and get presented with all the historical connections, etc. Instead, what if you add an "Add Table" button inside the Data Sources panel?: That is, under the triple dots in red, have a new option to quickly reuse that connection and add another table. Then you'd avoid the proliferation of connections, also (the yellow connection list, in my example). ... View more

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 ... View more

Hello, Currently the number of queries running in parallel during an EC build is set at the server level. With setting "Build / Base Table Max Threads" (4 by default). The optimised number of simultaneous queries is very much dependant on the context of the EC. For instance, an EC with 4 differents date source is more likely to accept a high number of simultaneous queries (spread over the 4 data sources), than an EC with only one data source. Therefore, I would like to suggest to make this setting per cube instead of at the server level. An alternative would be to have this setting at the Data Group level. Thank you and best regards, Franck   ... View more

Standard Live and Elasticube connector for AWS EMR: https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-connectors.html ... View more

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 ... View more

There are cases where the Sisense queries have to read from views. Would you consider allowing to issue queries like “ALTER database.materializedView REBUILD”  instead of only allowing select commands, in this case this would allow to refresh data that would be selected by the jdbc connector. ... View more

Some end-users have strict environmental and security constraints for their operations.  Please consider including M.I.T. Kerberos binaries and environment variable so that JDBC connectors could leverage Kerberos without having to access Kubernetes hosts machines. ... View more

Some of our customers are being forced to upgrade Mongo, and we need to upgrade our drivers in order to match. On 2023.7 we are using driver version 1.3.11 which is not compatible with MongoDB 4.2+ and our customers mentioned they are being forced to go to MongoDB version 5 or 6. ... View more

There are three features for BigQuery connections that would make your Edit Chart interface great. Show descriptions on the tables and fields: BigQuery supports adding a description to the fields and tables themselves. This information is often useful, and I find myself going to check the documentation on BigQuery consola in Google Cloud itself. We make use of this feature. Other databases also allow defining comments on tables and/or fields. It would be great to show them on the intervace via a tooltip when you put your mice over the field (right now is showing the type only) Display amount of data to be processed: one of the characteristics of BigQuery is that you pay by the amount of bytes you process. Building queries that are "efficient" is tricky task. Having a visual clue on the cost of the query allows me to understand better, before adding something in a dashboard or even running the query, how much data is going to consume. Also, if you tie that to the fact that I usually want to run the query using filters, and that there is no way for me to change filters in the editor, it makes my life miserable, because I need to copy the query, go to Google console, replace the generic filters [name=value] by real SQL filters, make a sense of the cost in SQL, etc... miserable experience. Show partitioned tables differently: For example, on Google Cloud BigQuery editor, partitioned tables are shown with a different icon than normal tables. Knowing if a table is partitioned, and knowing also which fields are the ones partitioned, would help to build efficient queries without leaving Sisense. Right now I find myself jumping in and out sisense. This takes time, and you are already showing all fields and tables in there, it would be great to just use a different icon for partitioned tables. That would be already helpful. Displaying the amount of data processed, to keep costs slim, would likely be the top thing (and Google does have API / command line in order to get the amount of bytes to be processed by a query). ... View more

Hello, How about having a better control over queries parallelism ? My use case : Elasticubes using 2 connections : DB1 / DB2 Currently, the parameter BaseTableMaxThreads (sets to 2 for us) controls how many queries can run in parallel, whatever the connection. During build, we frequently see situations where we have 1 query on DB1 and another one on DB2. Reducing the level of parallelism was necessary to limit contention on one connection but it would be fine to have 2 queries on DB1 and 2 queries on DB2 at the same time. My proposal is the following : having a parameters to controls the level of parallelism per connection and not per build. Thank you.    ... View more

I would like to be able to run a "lineage/dependency" report in Sisense. Something that will tell me for all the cube/live data sources: - Data source name - Type (cube/live) - Dates of the data model (created, modified, last built) - Data sources being referenced and type (web service, database, etc.) - Details of each data sources (SQL Server, servername, database name) - Tables or objects being referenced by those data sources It's important for managing the environment to know what we are using, or have an easy way to know what data sets/dashboards would break if a table's structure were changed in the database. ... View more

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. ... View more

It appears that once you've created a cube or live data set, you can't rename it. You can duplicate it, but I'd really like to rename some of our models without any of the associated dashboards breaking. ... View more

The idea of this is so you could show the elasticube data on the primary axis, and then potentially low latency data on a secondary axis - allowing easy comparison of live vs historical data ... View more

At the moment, the caching period of live models is set for the whole instance which removed flexibility where you'd want the caching period to be different for exceptionally large models.  For example, we have a table we have to ingest via a live connection as it is too big for elasticubes - but wouldn't want the caching period for this live connection to be too "low" as it would cost a lot via AWS.  However, we would want a low caching period for low latency reporting ... View more