https://www.gooddata.com/ logo
Join SlackCommunities
Powered by
Hi Team, <@U01PBHBUN4F> We are currently experienc...
# gooddata-cloud
a
Hi Team, @Michael Ullock We are currently experiencing an issue with a client, "Wentcher," in the production environment while attempting to pull their intake forms. Upon analysis, we have identified that GoodData is unable to properly escape double quotes within the questions, which is causing errors. Additionally, data from number fields/questions is being displayed incorrectly. We have client on standby because of this.
m
Hi Anjali, can you please reproduce the issue once again with your browser DEV tools opened and check the logs you see in the Console log and provide us with the Error details you see? Please copy the related Trace ID or Error ID related to this issue
a
Error Trace Id :0840d64802e93aefebc9015f1240f127
Screenshot 2025-02-10 at 3.42.22 PM.png
This error arises when double quotes are there in intake form question
Error Trace Id : 4803ccf40e2376a8b46b82f5fd911c6a while puling number fields for custom Intake response in GD
@Michael Ullock
m
I just wanted to let you know that I went ahead and accessed your workspace and used Impersonation on our internal Admin user to look into this and try and replicate this behaviour.
Hi Anjali, I just wanted to let you know that I have looped in our Tier 2 Technical team into this issue. Someone from the team will reach out to you with more details as they become available.
d
Hi Anjali. Thanks for pointing this out. We are looking into how double-quotes are parsed. As a quick workaround, would you mind renaming your attribute from 
If "other", please specify.
to something without the double-quotes? For example 
If OTHER, please specify.
As mentioned, this is just a quick workaround to make your workspace available. We are looking for a more long-term solution.
a
Client needs double-quotes , its important ingredient . Can you please check number field as well. @Daniel Stourac
cc @Pablo Castro
Trace Id:2ff0e9e24af67e5857ce6d63564b3bc9
Screen Recording 2025-02-13 at 12.49.48 PM.mov
d
Hi @Anjali Mandowara How did you enter the underlying SQL clause into GoodData? Can you send me a DM with the original SQL, please? It appears that your SQL is automatically generated from meta-information provided by your clients. Is that the case? In generating the SQL, you wrap every attribute name in double-quotes and create something like:
Copy code
SELECT "customFields"::jsonb->>'Fpn5S' AS "Profile" FROM "prod"."warehouse"
When your client uses double-quotes in their own attribute name, you end up with a construction like this:
Copy code
SELECT "customFields"::jsonb->>'3bsEanxz2' AS "If "other", please specify." FROM "prod"."warehouse"
Is this a correct assumption? Can you manually edit the SQL clause? If so, you can rename the attribute there and in the GoodData meta-information. GoodData separates the name of the DB column from the name it presents to the user = the user can still see the name with double-quotes while the DB will be presented with a name without them. Would this work for you? Right now, this whole SQL table (all its attributes) is inaccessible because of the additional double-quotes. The cause of this seems to be in the SQL clause used to define the table. But I would need to see the SQL in order to confirm this. Can you DM it to me?
a
@Daniel Stourac yes..the code through which i have pushed th data in GD defines "customFields"::jsonb->> '${field.id}' as "${label}"`
d
@Anjali Mandowara Thanks for the confirmation. This causes problems if ${label} contains quotation marks. Can you do some magic, such as removing (or replacing) quotation marks with something else in the ${label}? As long as you use the same label in the SQL and in the "sourceColumn" metadata key in LDM, it will work. The user will only see "title" and "description" LDM keys on their screen and will never know your ${label}. Would this work?
@Anjali Mandowara, as we continued the discussion in DM, let me summarize here for the community. You CAN add custom attributes to the data model programmatically by adding the new attribute to two places: the LDM and the associated SELECT statement for your custom SQL table. While it is perfectly OK to use quotation marks in the LDM, it causes problems in the SELECT statement, which is directly passed by GoodData to your database. For example, if your customer wants an attribute called 
my "favorite" boss
, the SELECT clause would look like this:
Copy code
SELECT ....., \"customFields\"::jsonb->> '1CH1nd' as \"my \"favorite\" boss\",
This will of course confuse the SQL interpreter, which will read the alias as two strings with operator 
favorite
between them rather than one string containing quotation marks. The solution is to: 1. Remove quotation marks from the attribute name in the SELECT and 2. Present a different name to the user. For example, you can replace the double quotes with the string QUOTE in the attribute name:
Copy code
SELECT ....., \"customFields\"::jsonb->> '1CH1nd' as \"my QUOTEfavoriteQUOTE boss\",
The attribute definition in LDM would then look like this:
Copy code
{
            "description": "My \"favorite\" boss",
            "id": "custom_profile_responses.1CH1nd",
            "labels": [],
            "sourceColumn": "my QUOTEfavoriteQUOTE boss",
            "sourceColumnDataType": "STRING",
            "tags": [
              "Custom Profile Responses"
            ],
            "title": "My \"favorite\" boss"
          },
Note that the sourceColumn matches the alias defined in the SELECT but is different from the title and description presented to the user. I hope it helps. Please, do let me know if there are problems with this solution.
2 Views
Open in Slack
PreviousNext
Powered by