Overriding get_db_prep_lookup seems like it would cause problems. Even if
were only registered when Oracle is in use, that would make multi-db with
Oracle as one of the backends problematic.
On Sat, Nov 15, 2014 at 5:46 PM, Josh Smeaton
wrote:
> Clever. I don't mind this approach at all. Will th
Clever. I don't mind this approach at all. Will the overriding of
get_db_prep_lookup interfere with other implementations though?
On Sunday, 16 November 2014 06:03:18 UTC+11, Shai Berger wrote:
>
> Hi,
>
> I'v been working on an old Oracle bug[1], and realized that a nice way to
> solve it woul
Hi Shai,
I was thinking about something very similar for the GIS backends, where
this question is even more accurate, as lookup implementations are often
very backend-specific.
I was experimenting with dynamic mixin registration, but that felt very
hackish [1]. Anyway, a solution to this use c
Today at “Django Under the Hood” sprints, one of the major features that we
expected for 1.8 was merged. Josh Smeaton has been working on “allowing
annotations to accept all expressions” for nearly a year! You may review
the results:
https://github.com/django/django/commit/f59fd15c4928caf3dfc
Tom, there's another way to remove confusion/decision making about import
ordering: https://pypi.python.org/pypi/isort
For Django it could be mentioned on the contrib docs and `isort
--check-only` run with flake8.
On Thursday, 13 November 2014 14:57:15 UTC+1, Tom Christie wrote:
>
> Contrary v
Hi,
I'v been working on an old Oracle bug[1], and realized that a nice way to
solve it would be by overriding some builtin lookups with custom lookups for
Oracle. However, I had some doubts about where to place the code:
On the one hand, I could just add an "as_oracle()" to the builtin lookup
Investigating https://code.djangoproject.com/ticket/21163
I came across these lines in mysql/base.py:
if settings.DEBUG:
warnings.filterwarnings("error", category=Database.Warning)
Finding out why, this bubbles up to somewhere in 2007
https://github.com/django/django/commit/f9c4ce51235aac48
Hello,
The Django team has been discussing the timeline for dropping
support for older Python versions. The current consensus is:
- Support Python 2.x until the LTS version after 1.8, which should
be released late 2017 or early 2018 and supported until 2020,
when official support for Python 2
Hello,
This timeline was discussed by the core team today at Django under the Hood and
approved.
The support period for Django 1.4 will extend for six months after the release
of Django 1.8.
The recommended way to migrate from 1.4 to 1.8 is to go through 1.5, 1.6, and
1.7. I encourage you to
