Throw exception when queries containing non-existence column
See original GitHub issuePinot doesn’t give error when users’ queries contain non-existence column in schema, but give empty result. It’s also misleading when users aggregation query is bad but Pinot gives 0.
For certain queries, Pinot should just throw exceptions with messages like Columns [A, B, C] don't exist in schema of table myTable
, instead of giving empty results.
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
sqlite3 - non existent columns in select or where not throwing ...
Using sqlite3, if I select from a non existent column, or add a non existent column in the where clause, no error is...
Read more >NHibernate tries to query in a nonexistent column
But when I try to query UsuarioConta, it returns me an error: Invalid column name 'Id'. Looking to NHibernate query, I could see...
Read more >3 Common Foreign Key Mistakes (And How to Avoid Them)
2. Dangling foreign keys. A dangling foreign key is a foreign key that links to a nonexistent table or column. This is obviously...
Read more >CAML: Possible to query non existing field?
The aim is, to use one query for the 2 lists and handle everything with 1 SPSiteDataQuery. The query in this manner, throws...
Read more >SQL error messages and exceptions - Oracle Help Center
42879, The ORDER BY clause may not contain column ' <columnName> ', since the query specifies DISTINCT and that column does not appear...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Correct. IMO the clean solution should be to enforce the schema on all segments so that they always have the same schema, and prune the bad queries on broker side. When a segment does not have a column in the schema, we can automatically generate the column with default values.
The behaviour created by DataSchemaSegmentPruner isn’t generally correct though, if segment 1 of table T has column A and segment 2 has columns A and B, select sum(A),sum(B) from T will ignore segment 1 and produce an incorrect sum over A but a correct sum over B.