Re: Proposing the removal of Oracle from the Django supported backend databases

[Carsten Fuchs]

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 Django was a huge help in 
getting me started.

I'm aware that this is a weak argument from unfortunately a code 
non-contributor (or indirect contributor at best) who is not shouldering the 
work and not even using the Oracle backend any more (we migrated to MySQL). But 
still, I would like to express my opinion that having Oracle in Django core is 
a worthwhile asset.

Best regards,
Carsten


Am 03.08.23 um 10:25 schrieb Paolo Melchiorre:
> Hi all,
> I wanted to share the frustration of seeing yet another great new ORM
> feature blocked due to Oracle compatibility:
> https://github.com/django/django/pull/16417
> 
> In the past, I too have had to put a lot of effort trying to make a PR
> compatible with Oracle, making the overall contributing experience
> much less pleasant and holding me back from contributing, especially
> in the early days.
> 
> Over the last few months, I've tried to encourage newcomers and young
> users to contribute to Django and they almost always ran into the need
> to provide compatibility to Oracle, so much so that they eventually
> gave up contributing.
> 
> I stress that I am absolutely not criticizing the contributors (very
> few) in the community who help overcome the difficulties with Oracle.
> 
> The point is that I think Oracle is a historical anomaly among the
> database backends supported by Django because it is the only one that
> is not Open Source, it has irrelevant usage numbers (see Django
> Developers Survey 2022 Results
> https://lp.jetbrains.com/django-developer-survey-2022/#horizontal-bar-chart-862)
> and the company that earns from it does not contribute in any way to
> its maintenance or support (see Carlton Gibson keynote at PyCon Italia
> 2023 https://youtu.be/AHjnGtaWDjU?t=836)
> 
> To add to all this we consider that developing for Oracle is much more
> difficult than for the other Open Source databases supported by Django
> and above all the new contributors to the ORM have a frustrating
> experience and therefore they are less and less.
> 
> I, therefore, suggest that we start a discussion on removing Oracle
> from supported databases.
> 
> Ciao,
> Paolo


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/199b5a9f-1b10-eb13-68ea-46a66cad609b%40cafu.de.

Conclusion of ticket #26761

[Carsten Fuchs]

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 
analogously to the help_text attribute of model fields.

For such an attribute, there are two places that it might affect:

  - the list page (where the help_text of a model field is available as a 
tooltip over a "(?)" mark in the column header)

  - the change object page (where the help_text of a model field is available 
as a message below the field's value)

Please see that attached image for an example.

Unfortunately, Mariusz closed the ticket with the argument that 
`short_description` could be used in place of `help_text`. However, to the best 
of my understanding, that is not right: `short_description` changes the *label* 
of the fields (in the screenshot "Lokaler Zeitpunkt" and "Bewertung"), but not 
the text below the values.

May this be reconsidered?

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8e72c318-f28d-465f-8707-47e77a5d0d20%40cafu.de.

Re: Can we move the activity on this list to the Forum now?

[Carsten Fuchs]

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 surprised that not more mailing list members argue in favor 
of the mailing list.

The mailing list makes it easy to read or at least glance at every single 
message, if desired, while enabling readers to skip uninteresting threads 
quickly. This is a lot more difficult on the forum, especially with the user 
interface as implemented by Discourse, which wastes a lot of white space (lines 
with much vertical spacing, as with the topic lines on the Latest page, are 
difficult to parse quickly) und whose „last visit“ line is unreliable, 
especially if you read the forum on multiple devices (home, office, mobile, …) 
with possibly several tabs open at the same time.

I'm aware that I'm in a minority and that there is no way to convince the 
relevant people to keep the mailing-lists, but in my opinion the switch the 
forum is a step backwards in accessibility, usability and easy of use.

Best regards,
Carsten

Am 04.05.23 um 07:49 schrieb Jure Erznožnik:
>
> This has been answered affirmatively in this very thread before.
>
> The forum even has a "Mailing list mode" in addition to several other mailing 
> options (including a nifty "activity summary").
>
> LP,
> Jure
>
> On 4. 05. 23 07:28, Curtis Maloney wrote:
>> Does the Forum allow me to get email notifications / summaries?
>>
>> If not, it will mean I disconnect with that part of the community.
>>
>> --
>> Curtis
>>
>> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>>> Yes please!
>>>
>>>
>>>
>>> On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com 
>>> (jure.erznoz...@gmail.com) wrote:
>>>

 +1

  

 *From:*django-developers@googlegroups.com 
  *On Behalf Of *natali...@gmail.com
 *Sent:* sreda, 03. maj 2023 20:10
 *To:* Django developers (Contributions to Django itself) 
 
 *Subject:* Re: Can we move the activity on this list to the Forum now?

  

 Hello everyone!

  

 I was wondering if we could make a decision about this topic. On the one 
 hand, and as far as I understand, the forum is the preferred channel of 
 communication. On the other hand, having multiple channels of 
 communication can spread important discussions too thin, making it 
 difficult to have productive conversations in one place.

  

 As a newcomer to the contributing community, I can attest that the current 
 situation causes some confusion. IMHO, the same applies to the chat 
 options: there is IRC and the Discord server (though perhaps I should 
 start a new forum topic about that in order to keep decisions separated).

  

 In summary, I'm +1 to "move on-mass (all few of us :) over there"!

  

 Thank you!

 Natalia.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ecfbf957-a2a6-4054-cc0e-a6274fa3c74e%40cafu.de.

Re: Can we move the activity on this list to the Forum now?

[Carsten Fuchs]

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 parse, e. g. when the mail 
client presents messages hierarchically in a thread-based view.

Best regards,
Carsten



Am 28.11.22 um 15:05 schrieb Carlton Gibson:
> Hey Roger, 
> 
> Indeed it does. You can set up Email Mode (that may not be the actual name) 
> and it’ll work just like a mailing list. 
> 
> You can also subscribe to just a particular category, so the Internals one 
> would map to the discussion on this list. 
> 
> 
> 
> On Monday, 28 November 2022, Roger Gammans  > wrote:
> 
> Hi
> 
> I can't speak for others, but I personally STRONGLY value the fact that 
> this discussion happens in my inbox, not on yet another website. 
> 
> But perhaps the forum still supports this reading mode?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bdf1ecf8-fc09-af26-1f9a-978b7bafcf29%40cafu.de.

#29120 and #29502: autocomplete requires view permission

[Carsten Fuchs]

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 comment:
https://code.djangoproject.com/ticket/29502#comment:1
> Good example would be a foreign key to a user. You don't want anyone but 
> superusers to have access to the user model, but you would have to in this 
> case.

Also mentioned by Carlton at:
https://code.djangoproject.com/ticket/29502#comment:1
> There's a slight inconsistency in that no permission to the related model is 
> needed if you don't use autocomplete.

Combined with https://code.djangoproject.com/ticket/29700, which was closed as 
wontfix, there is a dilemma:
Either give anyone who is supposed to work with the parent model view 
permission to the User model, or forego the autocomplete feature.

Would it be possible to remove the permission check from AutocompleteJsonView 
entirely?
Alternatively, another permission „view string representation“? That, imho, 
would be the clean and proper solution – but also the most elaborate and 
expensive.

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7847621-8331-8145-3484-02cfc417ae82%40cafu.de.

Re: About #33904, Many-To-Many field is deleted/ignored from internal JavaScript “filter” interface

[Carsten Fuchs]

Hi Carlton,

thanks for your reply!

I tried as you suggested with the stable/4.1.x branch, but the issue reported 
in #33904 persists.
My JavaScript skills are limited, but I also cannot see any relationship 
between the changes in 
https://github.com/django/django/commit/82e9e19ebe6bc920f1cfffc42d86648644fd4a78
 and the problem with the Many-to-many fields with JavaScript filters.
I'll reopen #33904 in a moment.

Best regards,
Carsten




Am 23.08.22 um 14:28 schrieb Carlton Gibson:
> Hi Carsten, 
> 
> Mariusz marked that as a duplicate
> 
> The fix was applied to stable/4.1.x here: 
> https://github.com/django/django/commit/82e9e19ebe6bc920f1cfffc42d86648644fd4a78
>  
> <https://github.com/django/django/commit/82e9e19ebe6bc920f1cfffc42d86648644fd4a78>
> 
> It'll be part of the next release. 
> https://docs.djangoproject.com/en/4.1/releases/4.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, Carsten Fuchs  <mailto:carsten.fu...@cafu.de>> wrote:
> 
> Dear group,
> 
> ticket https://code.djangoproject.com/ticket/33904 
> <https://code.djangoproject.com/ticket/33904> was closed with 
> https://code.djangoproject.com/changeset/0756c61f2ada56e4ae625589099c0141a77737eb/
>  
> <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 because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c83ca19a-92c2-d3b0-e65d-89c7aedc60e4%40cafu.de.

About #33904, Many-To-Many field is deleted/ignored from internal JavaScript “filter” interface

[Carsten Fuchs]

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 because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/82eabdca-b66a-6c70-8156-c664969bfffa%40cafu.de.

Re: Making startproject's settings more 12-factor-y

[Carsten Fuchs]

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
localconfig.example
localconfig.py

settings.py is the normal settings file.
localconfig.example is an example file for a local configuration, kept in 
version control.
localconfig.py is a customized copy of localconfig.example, not kept in version 
control.

localconfig.example and localconfig.py would contain e.g.:

DEBUG = False
SECRET_KEY = '1234'
# ...

and in settings.py:

from project_dir import localconfig

DEBUG = localconfig.DEBUG
SECRET_KEY = localconfig.SECRET_KEY

?

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce46b909-957f-4e7c-15e0-24d14492a195%40cafu.de.

After #28321 len(formset.forms) != len(formset.errors) is possible

[Carsten Fuchs]

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 `formset.forms` possibly no 
longer aligns with `self.errors`.

Was that intended?

The original ticket reporter suggested that for a deleted form with errors, an 
empty dict should be added to formset._errors in a formset's full_clean(). This 
would have preserved the alignment of formset.forms and formset.errors.

Note that the formset implementation often uses index-based iterations over the 
forms which seems to suggest, although there is no other indication or hint, 
that formset.forms[i] correlates to formset.errors[i] for all valid i. (That 
was also my understanding from the documentation before having looked at the 
implementation.)

[ In my application code I have the requirement that even deleted forms must 
meet certain validation criteria. Therefore I relied on the Django 1.11 / 
pre-#28321 behavior, where at the same time   formset.is_valid() == True   and  
 any(formset.errors) == True   was possible. While I found this undocumented, 
it was my preferred behavior. ]

Any thoughts?

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to 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/ca5755d2-f905-f9ed-a8a9-60704bdaac4d%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Deferring "Sign the CLA"

[Carsten Fuchs]

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:

http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to 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/be2411fd-7d1f-aa84-ead1-29f622a4507f%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Development story for CBV FormViews using GET

[Carsten Fuchs]

lt;mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email 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-989e-03a0a85d895a%40cantab.net
>  
> <https://groups.google.com/d/msgid/django-developers/668e083b-d3c1-8a5b-989e-03a0a85d895a%40cantab.net?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

-- 
Dipl.-Inf. Carsten Fuchs
Industriegebiet 3 ℅ Rofu
55768 Hoppstädten-Weiersbach
https://www.cafu.de

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to 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/202c45df-bceb-fb03-6441-b0e2dbe0ab37%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

[Carsten Fuchs]

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 this issue in pr
https://github.com/django/django/pull/4385. After the pr, you could just
use .filter(Q(entry__tags__name='django')&~Q(entry__author_count=2)).


Sorry for my late reply, and many thanks for yours, it's very much 
appreciated!  :-)


Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/565F6B69.4070800%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

[Carsten Fuchs]

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 somewhere. So, I don't think this argument is
convincing without the annotation (note that the place of the annotation
matters). In addition, providing example data and the expected results
would be great, too.


Well, yes, this is a fictional example, but if you replace author_count 
by some valid field that doesn't require an annotation, e.g. 
author__name, the (imaginary) query should be valid (for the purpose of 
demonstrating the problem)?


The key issue is really this, quoted from the linked Django documentation:


"To handle both of these situations, Django has a consistent way of processing
filter() calls. Everything inside a single filter() call is applied
simultaneously to filter out items matching all those requirements. Successive
filter() calls further restrict the set of objects, but for multi-valued
relations, they apply to any object linked to the primary model, not
necessarily those objects that were selected by an earlier filter() call."


That is, sometimes we *have* to put several filters into a single 
filter() call to obtain the desired set. If such a situation requires a 
negation, exclude() cannot help, because "[...], they apply to *any* 
object linked to the primary model, not necessarily those objects that 
were selected by an earlier filter() call".



The discussion seems to miss a real definition of what exactly the ne
lookup should do. There are two ways to implement ne, one is as a
complement of exact, another is as the != operator. In SQL the first one
is "col != val OR col IS NULL", the latter one is just "col != val".


Thanks for pointing this out, I wasn't aware of this (in this context) 
before. It seems to be another facet in the overall problem, but 
independent from the above, isn't it? (In my normal, "non-negated" 
queries, where required I account for NULLs explicitly all the time...)


Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56506174.4050609%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

[Carsten Fuchs]

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 consistency.


I think that this is where the communication problem is:

The "con" side seems to see a problem in the current API regarding 
exclude() (personally, about what it is I only have a vague idea from 
older linked discussions: NOT(...) vs. "proper" negation) and argues 
that fixing the problem solves the issue and avoids inconsistency in the 
API brought by the introduction of __ne.


The "pro" side sees a problem in functionality when __ne is lacking, and 
cannot see how the "con" side's arguments would help. The problem in 
functionality is detailed in 
https://code.djangoproject.com/ticket/5763#comment:14, which essentially 
quotes (possibly an older version of) 
https://docs.djangoproject.com/en/1.8/topics/db/queries/#spanning-multi-valued-relationships 
and shows a related example where exclude() cannot replace __ne. As we/I 
cannot see how fixing/changing exclude() would help in this situation, 
we keep asking about __ne.  ;-)


In summary, the imaginary query of comment 14

Blog.objects.filter(entry__tag__name='django', 
entry__author_count__ne=2)


seems quasi not be possible to implement in today's Django (but probably 
with your suggestion below).



Anyway, with the new lookup API, it has become trivial for any project
to implement the __ne lookup. It is the first example in the how-to
guide: 
https://docs.djangoproject.com/en/dev/howto/custom-lookups/#a-simple-lookup-example.


Thanks, I'll definitively check and try this out, I didn't know it before!

Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/565054EA.40508%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

[Carsten Fuchs]

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, 
> stop opening it" with no good reasoning or rationale behind it.
>

Dito.

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f174ac93-1ee1-4ec6-8219-091f84567b9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

[Carsten Fuchs]

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 exclude() is supposed to make __ne redundant?

Please see the examples at 
https://code.djangoproject.com/ticket/5763#comment:14  (sorry I gave a 
wrong comment number in my initial post, comment 14 is the right one). The 
comment seems to explain clearly how exclude() can *not* be used where __ne 
can.

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7fc93b8-d351-47f0-bf20-1de0365ba917%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

[Carsten Fuchs]

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 and the discussions linked 
>> from it, why should __ne not be implemented?
>>
>
> Because Django ORM __ne SQLAlchemy. 
>

Can you please tell how the examples at 
https://code.djangoproject.com/ticket/5763#comment:14  (sorry I gave a 
wrong comment number in my initial post, comment 14 is the right one) can 
be implemented with exclude() ?

Oh, and what is SQLAlchemy?   ;-)
(Really, I heard about it, but have never even looked at it.)

Best regards,
Carsten


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e640e0a-2c1b-4938-8326-d8faaf627b7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

__ne, #5763

[Carsten Fuchs]

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 https://code.djangoproject.com/ticket/5763#comment:23
That is, afaics, some queries cannot be formulated without __ne, as 
exclude() is not an equivalent. Or am I missing or misunderstanding 
something?
I can live with the existing work-arounds, so I'm mostly curious.   :-)

Best regards,
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0b0cbc2d-9fb1-4f74-a994-5598c2590b7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with creating a one-to-one instance

[Carsten Fuchs]

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 questions.


I'm very sorry.
Thanks for pointing me to the right places.

Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Problem with creating a one-to-one instance

[Carsten Fuchs]

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 below does wrong: 

With these models: 

class Vorblendplan(models.Model): 
# ... 
pass 

class Mitarbeiter(models.Model): 
# ... 
vbp = models.OneToOneField(Vorblendplan, null=True, blank=True, 
on_delete=models.SET_NULL) 

I try to make sure that a Mitarbeiter object has a proper (not None) vbp 
instance. In the manage.py shell: 

>>> ma = Mitarbeiter.objects.get(key="F426") 
>>> ma.vbp  # ok, initially "None" 
>>> ma.vbp = Vorblendplan() 
>>> ma.vbp.save() 
>>> ma.save() 

>>> ma = Mitarbeiter.objects.get(key="F426") 
>>> ma.vbp  # Why still "None"?? 

This, in contrast, works: 

>>> ma = Mitarbeiter.objects.get(key="F426") 
>>> ma.vbp  # "None" 
>>> v = Vorblendplan() 
>>> v.save() 
>>> ma.vbp = v 
>>> ma.save() 

>>> ma = Mitarbeiter.objects.get(key="F426") 
>>> ma.vbp  # ok, as expected 
 

Why does the first example not work? 

Any hint would very much  be appreciated!  :-)

Thank you very much, and best regards, 
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GitHub migration done!

[Carsten Fuchs]

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 hold off on making commits until the migration is done. 
>
> OK, it's live! 
> https://github.com/django/django 
>

Excellent job, thank you very much!

Please forgive me a side question though:
Why didn't you convert the feature branches when converting the repository 
from SVN to Git as well?
I'm asking this mainly because I'm relatively new to Git, and wonder how 
exactly do you plan to convert the branches (especially the long merged 
ones) at a later time? Wouldn't this unconditionally change the hashes of 
all commits subsequent to the merge (and thus be self-forbidding on a 
public repository? which in turn makes later adding of merged branches 
impossible?)

A thousand thanks to you all from a happy Django user!
Carsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/FvyJOQOt5r8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.