Hello Team, While doing the Data model setup for our staging parent workspace with staging connection, I encountered below error,

\\nDataset 'building_profile_images' reference to 'accounts_1' has different data type: 'INT' and 'null'
\\nDataset 'building_recurring_rules' reference to 'accounts_1' has different data type: 'INT' and 'null'
\\nDataset 'building_screen_installations' reference to 'accounts_1' has different data type: 'INT' and 'null'
...
...
\\nDataset 'time_logs_1' reference to 'job_trades_1' has different data type: 'INT' and 'null'
\\nDataset 'users_1' reference to 'organisations_1' has different data type: 'INT' and 'null'2
\\nDataset 'zoom_meetings' reference to 'users_1' has different data type: 'INT' and 'null'
\\nDataset 'zoom_phones' reference to 'users_1' has different data type: 'INT' and 'null'

But when checked in out DB we don't have such tables as attachments_1, account_1 ... *_1 suffix, but we have attachments, accounts ... tables with same name but without _1 suffix. So this _1 suffix is it some layer on your end GoodData ? Also imp point how can we make Null acceptable ? as these foreign references are optional in our DB, so we can have NULL values in foreign key columns. And also what is this 2 represent for "Dataset 'users_1' reference to 'organisations_1' has different data type: 'INT' and 'null'2" this specific error message row

New message text here

above points are useful but for 3.

Handling NULL Values in Foreign Key Columns

point, need more detail how and where can do this setting

Hello Shubham, The recommended approach is to create a database view (or SQL dataset within GoodData) that wraps your fact table and converts NULL foreign key values to a sentinel value (e.g.,

0

,

-1

, or

'NA'

). Then, add a corresponding "placeholder" row to the referenced dimension table. Example concept: 1. Create a view over your fact table that replaces NULLs:

SELECT

id,

COALESCE(foreign_key_col, -1) AS foreign_key_col,

-- other columns...

FROM your_fact_table

2. Add a placeholder row to your dimension table (e.g., with

id = -1

and a label like

'N/A'

), either directly or via a

UNION ALL

view:

SELECT id, name FROM your_dimension_table

UNION ALL

SELECT -1, 'N/A'

3. Point GoodData to these views instead of the raw tables. This ensures every foreign key value in the fact table has a matching primary key in the dimension table, satisfying GoodData's referential integrity requirement. Another option is to pre-join the Tables If the optional relationship is between two tables and a view-based approach is not feasible, you can pre-join the two tables into a single view and expose that combined view to GoodData as one dataset. This eliminates the need for a separate reference/foreign key relationship entirely. Kindly note that the fix must be applied at the data layer (your database or views) before GoodData reads the data. The data model validation in GoodData only checks structure and mapping, not the actual data contents, so it will not warn you if NULLs are present at runtime but they may silently cause incorrect query results. Let me know if this helps.