Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User-unfriendly behaviour when selecting rows by field value #33

Open
pont-us opened this issue May 9, 2022 · 0 comments
Open

User-unfriendly behaviour when selecting rows by field value #33

pont-us opened this issue May 9, 2022 · 0 comments

Comments

@pont-us
Copy link
Member

pont-us commented May 9, 2022

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:

  1. 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.

  2. 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.

  3. 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant