Changes between Version 1 and Version 2 of Ticket #34262, comment 15


Ignore:
Timestamp:
Feb 9, 2025, 9:09:13 AM (3 days ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #34262, comment 15

    v1 v2  
    99> Just thinking out loud here. If option 2 is the path forward,
    1010
    11 I think that raising awareness is the way to go here but I don't think that the proposed implementation of capturing errors and emitting warning is the way to go here. First because it's brittle given we don't know the extent of this problem and the MySQL implementation could change and secondly because it's not an approach we've taken with this class of problems.
     11I think that raising awareness is the way to go here but I don't think that the proposed implementation of capturing errors and emitting warning is how we should do it. First because it would be brittle given we don't know the extent of this problem and the MySQL implementation could change and secondly because it's not an approach we've taken with this class of problems.
    1212
    1313IMO this problem is very similar to how we let inappropriate casting errors bubble through and expect users to use `CAST` where necessary from the error messages over trying to detect such errors and point them directly at `django.db.models.functions.Cast`. In other words I think that it's better to have the user go through the following chain of thoughts
    … …  
    1717- Search for Django `CAST` / `ANY_VALUE` and endup on the `Cast` / `AnyValue` docs
    1818
    19 than committing to building a bullet proof solution that hides away these details from users. For all we know MySQL could finally implement functional dependency detection properly and all of our efforts (and bugs trying to get it right but failing) would be wasted efforts.
     19than committing to building a bullet proof solution that hides away these details from users. For all we know MySQL could finally implement functional dependency detection properly and all of our efforts (and bugs trying to get it right but failing) would be wasted.
    2020
    21 For these reasons I believe that ''raising awareness'' is effectively the way to go but I think the way to do so is
     21For these reasons I believe that the proper way of ''raising awareness'' here is to
    2222
    23231. Introduce an `AnyValue(Aggregate)`
    24242. Make sure the documentation mentions that its usage might be necessary on MySQL when mixing aggregate and non-aggregate functions when `sql_mode=only_full_group_by` in a `.. note`
    25 3. Link to `AnyValue` documentation from the [https://docs.djangoproject.com/en/5.1/topics/db/aggregation/#aggregating-annotations aggregating annotations] section of the docs
     253. Link to `AnyValue` documentation from the [https://docs.djangoproject.com/en/5.1/topics/db/aggregation/#aggregating-annotations aggregating annotations] section of the docs.
Back to Top