You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here, textcolumn has the text type in the database, but we're incorrectly trying to select with an integer. The result is a rather long backtrace (see backtrace.txt for an example from an AVL notebook) ending with an error message:
GeoDBError: {"hint":"No operator matches the given name and argument type(s). You might need to add explicit type casts.","details":null,"code":"42883","message":"operator does not exist: text == integer"}
Problems exemplified by this scenario:
Using a raw SQL snippet for a this common row selection task. Building the SQL is fiddly and error-prone (especially if one wants to use an IN clause rather than a plain ==) and there's no type checking until the SQL hits the database. The geoDB client should have a predefined function for such selections, which could check type correctness on the client side.
While the error message is relatively helpful in diagnosing the problem, it comes at the bottom of a 72-line backtrace which makes it difficult for a typical user to pick out the relevant line.
Near the top of the backtrace, there's another error: HTTPError: 404 Client Error: Not Found for url: [https://xcube-geodb.brockmann-consult.de:443/rpc/geodb_get_by_bbox](https://xcube-geodb.brockmann-consult.de/rpc/geodb_get_by_bbox). The 404 gives the misleading impression of some kind of server availability or routing problem and helps to mask the actual problem further down. Shouldn't this be a 400 or a 500?
The text was updated successfully, but these errors were encountered:
Consider the use case of selecting database rows using a field value match, but with an incorrect type:
Here,
textcolumn
has thetext
type in the database, but we're incorrectly trying to select with an integer. The result is a rather long backtrace (see backtrace.txt for an example from an AVL notebook) ending with an error message:Problems exemplified by this scenario:
Using a raw SQL snippet for a this common row selection task. Building the SQL is fiddly and error-prone (especially if one wants to use an
IN
clause rather than a plain==
) and there's no type checking until the SQL hits the database. The geoDB client should have a predefined function for such selections, which could check type correctness on the client side.While the error message is relatively helpful in diagnosing the problem, it comes at the bottom of a 72-line backtrace which makes it difficult for a typical user to pick out the relevant line.
Near the top of the backtrace, there's another error:
HTTPError: 404 Client Error: Not Found for url: [https://xcube-geodb.brockmann-consult.de:443/rpc/geodb_get_by_bbox](https://xcube-geodb.brockmann-consult.de/rpc/geodb_get_by_bbox)
. The 404 gives the misleading impression of some kind of server availability or routing problem and helps to mask the actual problem further down. Shouldn't this be a 400 or a 500?The text was updated successfully, but these errors were encountered: