I'm trying to use update_all to update any records that is missing a key in a JSON stored in a table cell. ids is the ids of those records and I've tried the below...
User.where(id: ids).
update_all(
"preferences = jsonb_set(preferences, '{some_key}', 'true'"
)
Where the error returns is...
Caused by PG::SyntaxError: ERROR: syntax error at or near "WHERE"
LINE 1: ...onb_set(preferences, '{some_key}', 'true' WHERE "user...
The key takes a string value so not sure why the query is failing.
UPDATE:
Based on what was mentioned, I added the parentheses and also added / modified the last two arguments...
User.where(id: ids).
update_all(
"preferences = jsonb_set(preferences, '{some_key}', 'true'::jsonb, true)"
)
still running into issues and this time it seems related to the key I'm passing
I know this key doesn't currently exist for the set of ids
I added true for create_missing so that 1 isn't an issue
I get this error now...
Caused by PG::UndefinedFunction: ERROR: function jsonb_set(hstore, unknown, jsonb, boolean) does not exis
some_key should be a key in preferences
You're passing in raw SQL so you are 100% responsible for ensuring that is actually valid SQL. What you have there isn't. Check your parentheses:
User.where(id: ids).
update_all(
"preferences = jsonb_set(preferences, '{some_key}', 'true')"
)
If you look more closely at the error message it was telling you there was a problem precisely at the introduction of the WHERE clause, and right after ...true' so that was a good place to look for problems.
Syntax errors like this can be really annoying, but don't forget your database will usually do its best to pin down the place where the problem occurs.
Related
I'm trying to use Query Variables in Grafana, the panel query source is PostgreSQL for QuestDB.
I have added the variable without any issue, but I'm unable to use the variable in Panel query since the variable values contains the spaces (SENSOR01 ON_OFF), also I'm unable to figure-out how to add single quote escape.
Following are the scenarios I tried:
Scenario1: this indicates due to space in the Variable value, on_off considered as separate word
where sensor_name = $sensor
db query error: pq: unexpected token: on_off
.
.
Scenario2: tried to add single quotes explicitly for the variable value, but there is generic error from source DB (QuestDB)
where sensor_name = concat('''', $sensor, '''')
db query error: pq: dangling expression
When tried Scenario2 approach directly in query of Variable, getting the same error
..
Scenario3: Hard-coded the variable value with space and with single quotes, but this giving me error with first part of the variable, looks like the hard-coded single quotes not passed here!
Error (Scenario3):
Is there any way/workaround to tackle this issue?
Could you just add the quotes directly in the query?
where sensor_name = '$sensor'
I have a similar grafana panel querying a questDB database using a variable and it works for me. This is my query:
select device_type, avg(duration_ms) as avg_duration_ms, avg(speed) as avg_speed, avg(measure1) as avg_m1, avg(measure2) as avg_m2 from ilp_test
WHERE
$__timeFilter(timestamp) and device_type = '$deviceType'
A rather hacky workaround would be to do:
where sensor_name = concat(cast(cast('&' as int) + 1 as char), $sensor, cast(cast('&' as int) + 1 as char))
This should work, but I'm pretty sure there is a better solution. Let me find it and get back to you.
Update. We may support Postgres syntax (which is '' escaping for a single quote char) in one of upcoming versions. For now, you'd have to use the above workaround.
I need to be able to use variables in table names - I basically have the same set of tables used for different types of data, so I would like to just have one dashboard and swapping between all types instead of always having to set up multiple identical dashboards.
My query is something like:
select * from table_$variable_name;
Where my list of possible variable is something like cat, dog, bird
I can seem to make this work, if I only put the variable as shown above I get the following error
Error 1146: Table 'table_$variable_name' doesn't exist
If I enclose it in curly brackets, I get this error instead.
Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '{bird}' at line 1
(i.e. with the selected variable actually being visible this time)
I'm not sure if the issue is having underscores in the table names, I tried putting underscores around my variables too to check and I had no luck with that.
Another thing I tried was gradually adding on to the table name, so e.g.
select * from table_$variable;
Still returns an error, but I can see the table name starting to form correctly
Error 1146: Table 'table_bird_' doesn't exist
However, as soon as I add another underscore, the variable is not picked up abymore
```Error 1146: Table 'table_$variable_' doesn't exist``
I'm sure it's something silly I am missing in the syntax of the query - anyone has any suggestions?
Using this https://grafana.com/docs/grafana/latest/variables/templates-and-variables/ for reference
As #arturomp suggests, use
${var:raw}
At least in my case, this was the solution that worked.
I found double square brackets work. e.g.
Rather than
select * from table_$variable_name;
use
select * from table_[[variable_name]];
I have a custom type with code similar to the following (shortened for brevity):
create domain massFraction as jsonb (
value->'h' > 0 and value->'h' is not null
);
Running this provokes the following error:
ERROR: type modifier is not allowed for type "jsonb"
The documentation makes no mention of json being a disallowed base type for a domain.
https://www.postgresql.org/docs/12/sql-createdomain.html
I also thought that it was perhaps the "not null" part of the constraint, which the documentation mentions is "tricky". Additionally, I've tried similar statements without any json operators. All of these seem to be disallowed.
I am obnoxiously prone to not reading documentation, and worse still about understanding documentation when I do bother to read it... so does it not exist, or am I looking in the wrong places to see if this is permitted? Why is it not permitted?
You're missing a CHECK after jsonb:
create domain massFraction as jsonb check (
value->'h' > 0 and value->'h' is not null
);
This results in another error:
ERROR: 42883: operator does not exist: jsonb > integer
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
I believe what you want is
CREATE DOMAIN massFraction AS jsonb CHECK (
CASE jsonb_typeof(value->'h')
-- only cast when it is safe to do so
-- note: this will reject numeric values stored as text in the json object (eg '{"h": "1"}')
WHEN 'number' THEN (value->>'h')::integer > 0
ELSE false
END
)
The error you're getting comes from the fact that you input is parsed as
CREATE DOMAIN massFraction AS jsonb(<modifier>) -- like in varchar(10)
As an aside I would recommend against using camelCase in postgresql, as massFraction is the same as massfraction (unless quoted) and postgresql will use the lowercased form when reporting errors, hints, etc.
When I am exporting data from one environment and importing it to another, I am seeing an ambiguous unique keys error. I did check the ambiguity but did not find anything would cause this violation.
I get the following error (there are several identical errors but only posting 1):
Error Begin
**insert_update ABClCMSParagraphComponent;&Item;catalogVersion(catalog(id),version)[unique=true,allownull=true];content[lang=en];creationtime[forceWrite=true,dateformat=dd.MM.yyyy
hh:mm:ss];modifiedtime[dateformat=dd.MM.yyyy
hh:mm:ss];name;owner(&Item)[allownull=true,forceWrite=true];uid[unique=true,allownull=true]
ABClCMSParagraphComponent,8796158592060,,,Error saving batch in bulk
mode [reason:
unique keys {catalogVersion=CatalogVersionModel (8796093186649#41),
uid=DMparaleftdescrip} for model ABClCMSParagraphComponentModel
(8796158657596#1) - found 2 item(s) using the same keys]. Will try
line-by-line mode.,
unique keys {catalogVersion=CatalogVersionModel (8796093186649#41),
uid=comp_000003UX} for model ABClCMSParagraphComponentModel
(8796158592060#1) - found 2 item(s) using the same keys
;Item111;abcContentCatalog:Staged;"< p >Hello < a href="">world< /a><
/p>";12.09.2017 07:04:12;18.09.2017 09:38:39;Feed Article -
Makeup;;comp_000003UX
Error End
What would be the reason why it's showing the ambiguous error?
The logs didn't show the error clearly with the 2 check boxes that were selected. When I deleted these 2 columns, owner(&Item) & creationtime, the script imported successfully.
Often, when no specific errors are shown, there was a error saving the item. In your case it might be the initial attributes "owner" and "creationdate". If the item is present, initial attributes cannot be changed.
I got some account issues in the SCN so I make a attempt here.
We switched to Unicode and got some issues with that. INFTY_TAB = PS+2. This coding gets an error that "the offset + length is exceeding".
I found some hints but couldn't really figure out how to fix this. And even when I manage to fix those errors I got a new error called 'Iclude-Report %HR_P9002 not found'. The IT is still there so is there something else I can check?
Definition of PS:
DATA: BEGIN OF PS OCCURS 0.
*This indicates if a record was read with disabled authority check.
data: authc_disabled(1) type c.
DATA: TCLAS LIKE PSPAR-TCLAS.
INCLUDE STRUCTURE PRELP.
DATA: ACRCD LIKE SY-SUBRC.
DATA: END OF PS.
TCLAS is a char(1) field.
This is the part where the error pops up:
INFTY_TAB = PS+2.
Error: I had to translate so sorry for some mistakes that could appear.
Offset and Length (=2432) exceed the length of the character based beginning (=2430) of the structure.
Depends on the length of INFTY_TAB. You have to explicitly set length:
INFTY_TAB = PS+2(length).
Official information is here. The important point to note is that the inclusion of SY-SUBRC (which is an INT4 field) places a limit to the range of fields you can access using this (discouraged) method of access.
ASSIGN field+off TO is generally forbidden from a syntactical
point of view since any offset <> 0 would cause the range to be
exceeded.
Although the sentence above is related to ASSIGN command, it is also valid for this situation.