Changes between Initial Version and Version 1 of Ticket #34771, comment 11


Ignore:
Timestamp:
Aug 12, 2023, 8:12:20 AM (15 months ago)
Author:
Yitao Xiong

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #34771, comment 11

    initial v1  
    1 I guess it's my bad that I didn't clarify myself in the beginning - the ask was not really to support this case, but to make it clearer why it's broken so people who's less familiar with SQL knows how to move forward. Many of our developers have been working with Django for years, but this is our first time seeing such an error and we all scratched our head for quite a bit to come to the bottom of it. To me personally, a SQL syntax error would be the last thing I'd expect from an ORM.
     1~~I guess it's my bad that I didn't clarify myself in the beginning - the ask was not really to support this case~~ Just realized I lied there... I did ask for a fix, mainly because the different behaviors between `.values()` then `.annotate()` VS `.annotate()` then `.values()` made me thinking that this was a case that Django could make work. But if implicitly adding the annotated field to `SELECT` is too tricky and bug prone, I think it'll be great if we can make it clearer why it's broken so people who's less familiar with SQL knows how to move forward. Many of our developers have been working with Django for years, but this is our first time seeing such an error and we all scratched our head for quite a bit to come to the bottom of it. To me personally, a SQL syntax error would be the last thing I'd expect from an ORM.
    22
    3 I was thinking to have Django block unsupported CASTs in this case in the beginning. It'll be ideal that this query was never attempted to run in MySQL. You said we can't document all DB caveats, I imagine there might be too many? Not sure how feasible that idea is then... Another idea would be maybe capture this error and throw an ORM layer error instead?
     3Can we have Django block unsupported CASTs in this case? It'll be ideal that this query was never attempted to run in MySQL. You said we can't document all DB caveats, I imagine there might be too many? Not sure how feasible that idea is then... Another idea would be maybe capture this error and throw an ORM layer error instead?
Back to Top