Hello,
when I got started with Django more than 10 years ago, I had inherited a legacy
project with an Oracle database for porting from PHP to Python. It might also
have worked out well if Oracle support had been a 3rd party package, but I can
say for sure that Oracle being a core feature of
Hello,
ticket #26761 was closed as wontfix, however I don't understand the reason.
https://code.djangoproject.com/ticket/26761#comment:19
The ticket's author asked to add a help_text-like attribute for read-only
fields that are specified via functions. The intention was for it to work
Hello,
unfortunately, the subject lines of the emails sent by the forum have the forum
category prepended. These prefixes are long and make it difficult to parse a
large number of emails quickly, which significantly reduces one of the main
strengths of mail(ing-list)s.
To be honest, I'm
Hello,
unfortunately, the emails sent by the forum have long prefixes in the subject
lines, e.g.
[Django Forum] [Django Internals/ORM] Multiple Database Switching
That makes the messages easy to filter by mail client software, but comes at
the cost of much visual clutter that is hard to
Dear group,
with https://code.djangoproject.com/ticket/29120 it was documented that the
change permission of the related model was needed, later
https://code.djangoproject.com/ticket/29502 reduced this from change to view
permission.
However, there is a problem that was well described in this
1.1/
> <https://docs.djangoproject.com/en/4.1/releases/4.1.1/>
>
> Can you give stable/4.1.x a try and confirm it fixes your problem? If it
> doesn't work please reopen the ticket with a comment to that effect.
>
> Thanks!
>
> On Tue, 23 Aug 2022 at 14:16, Cars
Dear group,
ticket https://code.djangoproject.com/ticket/33904 was closed with
https://code.djangoproject.com/changeset/0756c61f2ada56e4ae625589099c0141a77737eb/
However, it seems that that commit has a fix for #33893, not for #33904 ?
Best regards,
Carsten
--
You received this message
Hello,
Am 25.06.20 um 19:51 schrieb Kit La Touche:
> […] Once we see how this gets used, we can see about passing it a file
> instead of `os.environ`, […]
This is probably a stupid question, but what is the advantage of this (and env
vars) over this:
In project_dir/project_dir:
settings.py
Dear group,
I just upgraded from Django 1.11 to 2+ and thereby found
https://code.djangoproject.com/ticket/28321
The ticket was resolved with commit
https://github.com/django/django/commit/f32d24652b920135eb6a0f3de74599f03e181731
Well, this change leaves us with a situation where
Am 01.05.19 um 01:11 schrieb Tobias McNulty:
> In the absence of information to the contrary, I'd hazard a guess that we
> still need the CLAs...
I don't know to what extend this applies to Django, but here someone argues
that CLAs are not necessary at all:
mail to django-developers@googlegroups.com
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/668e083b-d3c1-8a5b-9
Dear Anssi,
Am 2015-11-22 um 13:53 schrieb Anssi Kääriäinen:
The author_count name suggested this was an aggregation. If this is just
a regular field, then things are a bit simpler. Note that negated
Q-object + filter and exclude() queries are the same thing.
[...]
There is a fix for exactly
Hi Anssi,
Am 2015-11-21 um 12:50 schrieb Anssi Kääriäinen:
In summary, the imaginary query of comment 14
Blog.objects.filter(entry__tag__name='django',
entry__author_count__ne=2)
This isn't a real query. There isn't a field author_count, the query
needs an annotation
Hi Marten,
Am 2015-11-21 um 11:53 schrieb Marten Kenbeek:
The 'con' side argument is that it would create in inconsistency in the
API, since we don't have any other negated lookups either. If we can get
the same behaviour by fixing the current API, Django should not
introduce an unnecessary
Am Samstag, 21. November 2015 02:27:42 UTC+1 schrieb Aaron C. de Bruyn:
>
> With all due respect, looking through the ticket and reading responses
> shows me that the 'pro' side has good use cases for __ne, and the 'con'
> side basically says "use exclude" or "a core committer close the ticket,
Hi James,
Am Samstag, 21. November 2015 02:56:45 UTC+1 schrieb James Bennett:
>
> 8 years later, I still think we should figure out how to make exclude() do
> what people expect it to do, rather than implement another lookup type that
> overlaps with it.
>
What really confuses me is how
Hi Marcin,
Am Samstag, 21. November 2015 02:22:10 UTC+1 schrieb Marcin Nowak:
>
> On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote:
>>
>> sorry if this is a stupid question, but after having read
>> https://code.djangoproject.com/ticket/5763 an
Hi all,
sorry if this is a stupid question, but after having read
https://code.djangoproject.com/ticket/5763 and the discussions linked from
it, why should __ne not be implemented?
Without __ne, I'm experiencing the same problems that asmoore82 described
at
Hi Jacob, hi Florian,
Am 19.04.2013 18:18, schrieb Jacob Kaplan-Moss:
Unfortunately, we can't help you. Django-developers isn't a "second
level" for django-users; they're completely different lists. The
purpose of this list is to discuss the development of Django itself,
not answer user
Dear Django devs,
sorry to bother you here, but I posted to django-users first
(https://groups.google.com/d/msg/django-users/WHnCxHkEVjE/9puR4youvwsJ) and
there was no reply, so please let me re-try here:
I'm probably overlooking something very simple, but still cannot explain
what the code
Hi all,
On Saturday, April 28, 2012 5:08:09 AM UTC+2, Adrian Holovaty wrote:
>
> On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote:
> > We're going to do the migration to GitHub today. This means we'll no
> > longer be committing code to our Subversion repository. Committers,
> > please
21 matches
Mail list logo
