-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Consider the use case of selecting database rows using a field value match, but with an incorrect type:
gdf = geodb.get_collection_by_bbox(collection="mycoll", database="mydb",
bbox=bbox, comparison_mode="contains",
bbox_crs=4326, where="mydb_mycoll.textcolumn == 123" )
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?