-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix view v1 on tables #15427
Fix view v1 on tables #15427
Conversation
QA Wolf here! As you write new code it's important that your test coverage is keeping up. |
@@ -1,5 +1,3 @@ | |||
// TODO: datasource and defitions are unions of the different implementations. At this point, the datasource does not know what type is being used, and the assignations will cause TS exceptions. Casting it "as any" for now. This should be fixed improving the type usages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All these TODOS are not needed anymore
@@ -21,7 +21,7 @@ export default class ViewFetch extends BaseDataFetch<ViewV1Datasource, Table> { | |||
|
|||
getSchema(definition: Table) { | |||
const { datasource } = this.options | |||
return definition?.views?.[datasource.name]?.schema | |||
return definition?.views?.[datasource?.name]?.schema |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was causing errors when trying to fetch the data, as at some reactivity updates the datasource was undefined
Description
Fixing broken tables for viewV1, probably broken during the typification of the data fetchers: https://github.com/Budibase/budibase/pull/15295/files
This PR fixes it, while ensuring that not extra calls are made during some initialisation of forms or similar (we had that case in the past with some changes)
Launchcontrol
Fixing tables for viewV1