I have overridden the "RADIANS" function implementation from django in our
conftest.py file. Details not that important, but essentially is this:
```
connection.create_function("RADIANS", 1, lambda x: math.radians(float(x))
if x is not None else None)
```
The issue is, there is a lat/lon field in our database, which is stored as
a CharField (we can debate that decision later...), so when it gets passed
into the `_sqlite_radians` function the test fails as it is invalid input.
I think that these functions should be able to take in string values.
I have started a PR but thought before I submit it I should see if it is a
'genuine' bug or a decision not to support this field.
--
Ticket URL: <https://code.djangoproject.com/ticket/34863>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> We have a view that performs some trig calculations. It works when
> testing in MySQL, but fails when using sqlite.
>
> I have overridden the "RADIANS" function implementation from django in
> our conftest.py file. Details not that important, but essentially is
> this:
>
> ```
> connection.create_function("RADIANS", 1, lambda x: math.radians(float(x))
> if x is not None else None)
> ```
>
> The issue is, there is a lat/lon field in our database, which is stored
> as a CharField (we can debate that decision later...), so when it gets
> passed into the `_sqlite_radians` function the test fails as it is
> invalid input. I think that these functions should be able to take in
> string values.
>
> I have started a PR but thought before I submit it I should see if it is
> a 'genuine' bug or a decision not to support this field.
New description:
We have a view that performs some trig calculations. It works when testing
in MySQL, but fails when using sqlite.
I have overridden the "RADIANS" function implementation from django in our
conftest.py file. Details not that important, but essentially is this:
`connection.create_function("RADIANS", 1, lambda x: math.radians(float(x))
if x is not None else None)`
The issue is, there is a lat/lon field in our database, which is stored as
a CharField (we can debate that decision later...), so when it gets passed
into the `_sqlite_radians` function the test fails as it is invalid input.
I think that these functions should be able to take in string values.
I have started a PR but thought before I submit it I should see if it is a
'genuine' bug or a decision not to support this field.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34863#comment:1>
* status: new => closed
* resolution: => invalid
Comment:
Thanks for this ticket, however `radians` should not accept strings. You
can cast values before passing them to this function.
--
Ticket URL: <https://code.djangoproject.com/ticket/34863#comment:2>
Comment (by Zachary Croker):
Replying to [comment:2 Mariusz Felisiak]:
> Thanks for this ticket, however `radians` should not accept strings. You
can cast values before passing them to this function.
Hi Mariusz, the sqlite docs specify that these functions should accept
strings (see https://www.sqlite.org/lang_mathfunc.html)
"The arguments to math functions can be integers, floating-point numbers,
or strings or blobs that look like integers or real numbers. If any
argument is NULL or is a string or blob that is not readily converted into
a number, then the function will return NULL."
Also - in this instance I am unable to cast the values because they are
calculated wholly within the view (which I can't change)
--
Ticket URL: <https://code.djangoproject.com/ticket/34863#comment:3>
* resolution: invalid => wontfix
Comment:
Replying to [comment:3 Zachary Croker]:
> Hi Mariusz, the sqlite docs specify that these functions should accept
strings (see https://www.sqlite.org/lang_mathfunc.html)
We're trying to unify behavior for all backends. Accepting strings on
SQLite may be confusing.
Please [https://docs.djangoproject.com/en/stable/internals/contributing
/triaging-tickets/#closing-tickets follow the triaging guidelines with
regards to wontfix tickets] and take this to DevelopersMailingList or the
Django Forum, if you don't agree.
--
Ticket URL: <https://code.djangoproject.com/ticket/34863#comment:4>