Refresh schema for all tables
Summary: The discussion, initiated by Tim von Ahsen, revolves around the process of refreshing the schema for all tables in a database. jhone David explains that this involves updating the database structure, which includes modifying table definitions and adjusting indexes and keys. Edward James shares an issue where schema refreshes were not updating tables properly due to cached metadata and resolved it by clearing caches and revalidating connections. Sinclair Sinclair adds that running migration scripts or using built-in schema refresh features are also common methods to manage schema updates.
Can we get a "refresh schema for all tables" button?
Reason:
Our tables are usually "Select * From AnalyticsSchema.ViewName". We control which fields to return by editing the view, not the Sisense table definition. When a field gets added/removed/changed, we need to refresh schema. That's fine to do manually as you're working on that datamodel+views, but we need to refresh all when:
- We copy a datamodel to a different server. We need to refresh schema at least to double-check that the views are as expected on the new server. (If any fields have changed, then I'll need to go fix any widgets using those fields, or, more likely, update the view to include them.)
- A view gets edited, perhaps for a different datamodel, and my datamodel hasn't been updated.
- I edit several views and want to refresh schema for all those Sisense tables. If I've changed used fields then I'll need to go into each table manually anyway so it doesn't matter, but I've had a case where I've removed unused fields from several views and now I need to click refresh schema on every table individually.
Sinclair Sinclair
·2 months agoThis process typically involves running migration scripts, applying
ALTER TABLEcommands, or using a database Gebelik Hesaplama tool’s built-in schema refresh feature to reload metadata.Edward James
·3 months agoHi everyone, I’ve also faced a similar issue where schema refresh wasn’t updating all tables properly, and in my case it was mainly due to cached metadata not being fully cleared and some data sources not re-syncing during incremental refresh, so the fix that worked was to trigger a full model refresh after clearing cache and revalidating all connections, which helped ensure all tables updated correctly and reflected the latest schema changes. While looking into related configuration terms, I also came across a helpful reference on lawdefiner.com that helped me understand some of the setup terminology better.
jhone David
·3 months agoRefreshing the schema for all tables involves updating the database structure to reflect the latest design, relationships, and constraints. This process typically includes modifying stainless fasteners table definitions, adding or removing columns, updating data types, and ensuring indexes and keys are properly aligned with current requirements.
rushui5
·8 months agogreat and clean baju raya
Tim von Ahsen
OP1 year agoOleksandr_K : The option isn't there in L2025.1.0.627.
Maybe it appears only after a build has succeeded? I needed it for a never-before-built model.
(My use case is: I imported a .smodel file to a new server and switched it to a new source database. I want to refresh schema in case the new source has any differences to the old source.)
Tim von Ahsen
OP1 year agoHi Lonaav2122
I usually create views in my database that return what I need in Sisense, then in Sisense just select from those, instead of selecting from tables or writing queries in Sisense. Those views select columns explicitly, not *. You might like to also throw in cast-as-datatype statements so the datatype doesn't change unexpectedly.
That way, the columns returned change only when you do it deliberately, so when you refresh schema you already know whether columns are changing. If the underlying tables change, then your views return an error. You have to go point them at the new column names.
Using views also means you can re-use the same views in other data models, analytics tools, queries and views, and you can manage it all in SQL instead of in the data model. That does have the downside that if you want to change a view you have to find and test every data model that depends on it, but for us the upsides outweigh the downsides, and we use conventions, documentation, and automation to help.
It's best if you can query a database that doesn't keep changing columns. But that might not be practical. Are you querying views built for other reports that other people change when they modify their report? I've sometimes started a data model that way, but then copied their query into a new view for my report.
Lonaav2122
·1 year agoHi folks,
I’m trying to refresh the schema for all tables in my app’s database, but I’m unsure of the most efficient way to do it without causing data inconsistencies.
Is there a way to automate this safely for all tables without breaking the existing structure?
While working on the database, I’ve also been testing feature-rich apps like spotify premium apk, which rely heavily on seamless content syncing — something I’m aiming for too!
poppyplaytime
·10 months agoHi! Unfortunately, there isn’t a built-in option in Sisense to refresh all table schemas at once. The safest and most efficient way is to use the Sisense REST API to automate schema refreshes for all tables programmatically. This avoids manual work while keeping your data model consistent.
If you’re concerned about structure or dependencies, test the script on a staging model first to ensure no fields or relationships break. It’s a smart approach—similar to how apps like this website seamless syncing through controlled updates.
dudatadude
·9 months ago · Editedpoppyplaytime - could you elaborate on using the Sisense REST API to automate schema refreshes for all tables programmatically?
I've been trying to do this via /api/v2 endpoints but still getting the "Refreshing Schema: Differences Detected" popup:
Tim von Ahsen
OP10 months agoThere is now a button to refresh all schemas in a data model: Open the data model, click on the three dots at the top right, click Refresh Tables Schemas.
Tim von Ahsen
OP1 year agoCool! I will try it once we upgrade.
DRay
·1 year agoHello Tim,
Can you look at the option provided by Oleksandr_K and let us know it addresses your request?
Thank you.
Oleksandr_K
·1 year ago · EditedHi,
I would like to inform that since L2024.3 there is ability to refresh scheme for all tables of data model in 1 action. Feel free to try it out through 3 dots context menu in the top right corner of the data model.
Tim von Ahsen
OP2 years agoHi DRay,
No luck, I'm afraid.
The post you mention describes how to change connection information, but not the table's schema. It mentions an "autoRefresh" property, but that's about whether the LiveModel re-loads data at regular intervals or on-demand, nothing to do with refresh schema.
Sounds like the API can edit a table's schema, but there isn't a "refresh schema" endpoint. So, we could build our own tool that uses the API, but it would need to connect to the database to find column names and datatypes, and then update tables with those. That's doable, but quite a bit of work. Found this post that discusses that: https://community.sisense.com/t5/build-analytics/refresh-the-schema-to-a-table-through-the-api/m-p/5163
DRay
·2 years agoHello Tim and bobfroncko,
Can you take a look at this post and let us know if addresses your use-case? https://community.sisense.com/t5/knowledge/how-to-update-live-model-dataset-configuration-through-api-call/ta-p/6415
Thank you.
bobfroncko
·2 years agoOur data model changes pretty frequently by design, and currently the nightly cube builds do not pick up on these changes. We have to go in and manually refresh the schema in the UI. Originally it was fine, but now as we approach hundreds of cubes deployed, manually updating the UI is not ideal...
Would love an option to allow the rebuild to also refresh the schema so we didn't have to continue to manually update the schemas. Understand the risk associated with automated schema refreshes, but again this is by design for us so there would be no risk.
Thanks.