Re: Fellow Reports - August 2022

Week ending August 28, 2022 *Triaged: * https://code.djangoproject.com/ticket/33954 - NaN can be stored in DecimalField but cannot be retrieved (accepted) https://code.djangoproject.com/ticket/33955 - AttributeError in admindocs ViewDetailView (accepted)

Re: Fellow Reports - August 2022

Week ending August 21, 2022 *Triaged: * https://code.djangoproject.com/ticket/33925 - Testing tools Management Commands example fails (invalid) https://code.djangoproject.com/ticket/33916 - Support for serialization of combination of Enum flags. (accepted)

Re: modelform_factory and __module__ name

That helps, thanks. I don't think it's worth it either, because, ultimately, it'll still be "wrong". The right __module__ is wherever you called modelform_factory from. The perils of meta programming... On Monday, August 29, 2022 at 11:33:50 AM UTC+2 j.bre...@netzkolchose.de wrote: > Looks to

Re: modelform_factory and __module__ name

Looks to me like being carried forward from the very first metaclass ``MediaDefiningClass``, which happens to be defined in django.forms.widgets. Should be fixable by explicitly adding a __module__ notion to type(). Not sure though if it is worth additional code just for the sake of pretty

Re: Change `to_python` and `to_url` to be class methods on path converters

Thank you for your response! > [...] Keeping responsibilities separate ("convert slugs to/from URL's" versus "be a slug") is a generally desirable property. [...] While I do agree with you, I'm kind of wondering if it's desirable that Django enforces how and when the responsibilities are kept

Re: A generic cache decorator around low level cache api

It doesn't necessarily have to be a QuerySet; any function or method that takes some processing time could be decorated (e.g., an external call to an API). My aim is to reduce this code: def do_some_processing(): cache_key = "key" if cached_value := cache.get(cache_key):

Re: A generic cache decorator around low level cache api

I'm not sure I quite understand your proposal. Are you suggesting a decorator that caches the results of every queryset that is resolved within the decorated function? If so, I'm not sure how useful it would be. First, if a single query is problematic, there’s normally a way to optimize it within

Re: Ticket #32118 Add field for 4-bytes floats (RealField/SmallFloatField)

> Can Django have a RealField that automatically does the cast? I dont think it is a good idea to go that route in django and add that as a standard django field, mainly for these reasons: - FloatField happens to align correctly between pythons only "native" float type and the chosen db

Re: Change `to_python` and `to_url` to be class methods on path converters

I can see the appeal of allowing you to have fewer classes, but I don't think that's a good thing in itself. Keeping responsibilities separate ("convert slugs to/from URL's" versus "be a slug") is a generally desirable property. This change would also complicate the URL parsing process: it would

Re: Make timeout property for PasswordResetTokenGenerator

Hey Robert. > ... the argument here is "we don't want to", but the reasoning behind that is unclear ... For me, the reasoning would be that we get several security reports against Django pretty much every week, and the extent to which we make security sensitive areas **generic** for the sake of

Re: Feature Request (have sample implemenation): ALL subquery

I'm no expert on how PG optimises queries but NOT EXISTS appears to produce the desired execution plan. My original rationale was to improve the readability and "solution accessibility" for lack of a better term. This all came about because a colleague couldn't figure out how to do it as a

Re: Feature Request (have sample implemenation): ALL subquery

Hello David, Do you know if ALL provides any performance benefits over NOT EXISTS? Given we already support Employee.objects.filter( ~Exists(Employee.objects.filter( manager=OuterRef("pk"), join_date__gt=OuterRef("join_date") ) ) If it's not the case I'm not sure

Re: Make timeout property for PasswordResetTokenGenerator

Hey Carlton, I'm reading through the replies and I feel like I'm missing point completely. First some background - `PasswordResetTokenGenerator` is heavily referenced over the web (or more accurately - the `default_token_genrator`) when it comes to account activation. I personally believe the

Re: Named Groups for Enumeration Types

Hi Steven I agree that grouped choices would be nice to support in the enum types. Thank you for taking a look at this. I'm not sure about either of your proposed syntaxes. They both seem error prone and unclear to me. I propose instead using a separate grouping attribute: class

Re: Feature Request: get_default_backend() in django.template.Engine

Improving the docs sounds good. I think it would also be worth renaming engines to backends, and EngineHandler to BackendHandler, or similar. Yes it would require a deprecation cycle, but I also imagine 99% of projects would be unaffected. On Tue, Aug 23, 2022 at 8:39 PM Peter Thomassen wrote:

Re: Feature Request: get_default_backend() in django.template.Engine

Hi Carlton, On Mon, Aug 22, 2022 at 6:21 AM Carlton Gibson wrote: The current get_default() behaviour was only added to allow folks manually creating `Template("My String")` instances to continue to operate with multiple Django backends defined (#27359) — the initial assumption there was that

Re: #21978 include production-ready web server

g anywhere too soon is it?) >> > >> > But to cut back to your point, I don't know that we need to **include** >> a server — just make it easy to get going. These days pip install + a line >> in INSTALLED_APPS doesn't seem too much to ask (I think.) >> > >> >

Re: #21978 include production-ready web server

PPS doesn't seem too much to ask (I think.) > > > > Was it really 4 years ago Tom left that comment on #21978  (We'd > finally close this as wontfix: Django doesn't ship a webserver.) > > > > Does that fit in your view, or would that scenario not be good enough? > >

Re: #21978 include production-ready web server

as it really 4 years ago Tom left that comment on #21978  (We'd finally > close this as wontfix: Django doesn't ship a webserver.) > > Does that fit in your view, or would that scenario not be good enough? > > Kind Regards, > > Carlton > > On Tue, 23 Aug 2022 at 16:56,

Re: #21978 include production-ready web server

e, 23 Aug 2022 at 16:56, Peter Baumgartner wrote: > Hi all! I'd like to re-open the discussion around > https://code.djangoproject.com/ticket/21978 > > As a "batteries included" framework, Django kind of leaves people to > fend for themselves when it comes to deployment. Th

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

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

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

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 It'll be part of the next release. https://docs.djangoproject.com/en/4.1/releases/4.1.1/ Can you give stable/4.1.x a try and

Re: Make timeout property for PasswordResetTokenGenerator

Yes, likely. My point was (merely) that we **don't** want to add additional extension points to PasswordResetTokenGenerator. On Tue, 23 Aug 2022 at 12:58, Roger Gammans wrote: > Hi > > If it's intended as a reference implementation, then I would expect > PasswordResetTokenGenerator to use

Re: Make timeout property for PasswordResetTokenGenerator

Hi Carlton! I can understand what you're saying, and I don't think the TimestampSigner solution is bad But again, it's a little unclear why in the end, in line 132 of https://github.com/django/django/blob/7e6b537f5b92be152779fc492bb908d27fe7c52a/django/contrib/auth/tokens.py#L132 we assign

Re: Make timeout property for PasswordResetTokenGenerator

Hi If it's intended as a reference implementation, then I would expect PasswordResetTokenGenerator to use Signer or TimestampSigner internally , but I was surprised to discover that it didn't use either. Isn't those entry points the better API to advise for use rather than the direct use of

Re: Make timeout property for PasswordResetTokenGenerator

Hi Alexander. I think the point from ticket #30423 is that we don't want to complicate PasswordResetTokenGenerator in order to make it into a more general purpose token generator. Much better is for you to take inspiration from it to implement what you need in your project. (It's the underlying

Re: Make timeout property for PasswordResetTokenGenerator

Hi Max! Thanks for your answer But honestly, I don't really understand how You can check if super returns false not from the last 'if'. Now the function has 5 places where it can return False, and yes, we don't like the last case specifically. But to be honest I don't see a way to check the

Re: transaction.on_commit() proposal

I'd also be okay with a docs change, although this wouldn't help avoid late-binding bugs quite so much. On Mon, Aug 22, 2022 at 1:51 PM Carlton Gibson wrote: > Related ticket from this weekend, suggesting a docs change: > https://code.djangoproject.com/ticket/33939 > > On Mon, 22 Aug 2022 at

RE: Make timeout property for PasswordResetTokenGenerator

Hi Alexander. You can simply override ‘check_token’ to avoide this harcoded settings.PASSWORD_RESET_TIMEOUT on the 57 line. And for yours task it can be with super call and after add additional check. It is only some additional lines: MyСlassFromPasswordResetTokenGenerator(…):

Re: transaction.on_commit() proposal

Related ticket from this weekend, suggesting a docs change: https://code.djangoproject.com/ticket/33939 On Mon, 22 Aug 2022 at 14:11, 'Adam Johnson' via Django developers (Contributions to Django itself) wrote: > Hi > > I just wrote a blog post on a late-binding bug that can occur with using >

Re: Feature Request: get_default_backend() in django.template.Engine

Hi Peter. I agree with you that the documentation isn't that clear here. *"Why are there two template classes?", "Why does one take a dict and the other a Context?"* — that comes up.  I don't think your suggestion itself it that unreasonable, but I'm wary about expanding the API here, at

Re: Allow for strict mode in templates

Django logs warnings for missing variables. I believe this logging was added since that ticket was closed. I recently wrote a blog post with some techniques you can use to hook into this logging and turn those errors into exceptions:

Re: More user friendly delete confirmation template

Sounds good. (You mentioned adding an additional template block. You could put that in a commit to look at as well if you think it's of value to you.) On Wed, 17 Aug 2022 at 08:14, Jacob Rief wrote: > On Wednesday, August 17, 2022 at 7:23:35 AM UTC+2 Carlton Gibson wrote: > >> > Can we at

Re: More user friendly delete confirmation template

On Wednesday, August 17, 2022 at 7:23:35 AM UTC+2 Carlton Gibson wrote: > > Can we at least agree to put an id="..." onto the element wrapping > that list. > > That seems pretty minimal.  Do you want to open a PR so we can have a > look? > Okay, will do that. Any suggestions for a name? My

Re: More user friendly delete confirmation template

> Can we at least agree to put an id="..." onto the element wrapping that list. That seems pretty minimal.  Do you want to open a PR so we can have a look? On Tue, 16 Aug 2022 at 21:58, Jacob Rief wrote: > Can we at least agree to put an id="..." onto the element wrapping > that list. >

Re: More user friendly delete confirmation template

Can we at least agree to put an id="..." onto the element wrapping that list. That would help me to add some JS and CSS to the overwritten delete_selected_confirmation template without having to copy a huge block of HTML code from that template. – Jacob -- You received this message because

Re: Fellow Reports - August 2022

Week ending August 14, 2022 *Triaged: * https://code.djangoproject.com/ticket/33902 - UniqueConstraint's validation crashes with string expressions. (accepted) https://code.djangoproject.com/ticket/33904 - Many-To-Many field is deleted/ignored from internal JavaScript “filter” interface

Re: More user friendly delete confirmation template

אורי u...@speedy.net On Tue, Aug 16, 2022 at 3:55 PM 'Adam Johnson' via Django developers (Contributions to Django itself) wrote: > Collapsing the list of to-be-deleted objects could also lead to cases of > accidental removal of related objects. I think it's better to err on the > side of

Re: More user friendly delete confirmation template

The least intrusive change would be to add an id="..." to the -element wrapping that list. This at least allows me to add such a Javascript snippet into {% block extrahead %}. – Jacob -- You received this message because you are subscribed to the Google Groups "Django developers

Re: More user friendly delete confirmation template

On Tuesday, August 16, 2022 at 4:23:03 PM UTC+2 Carlton Gibson wrote: > > Then as Maxim points out, this is already possible with overriding the > template. > > That's what I did of course in the first place. It however turns out that you have to copy quite a bunch of boilerplate code, the

Re: More user friendly delete confirmation template

;> >> >> *From:* 'Adam Johnson' via Django developers (Contributions to Django >> itself) [mailto:django-developers@googlegroups.com] >> *Sent:* Tuesday, August 16, 2022 2:55 PM >> *To:* Django developers (Contributions to Django itself) < >> django-develope

Re: More user friendly delete confirmation template

Adam Johnson' via Django developers (Contributions to Django > itself) [mailto:django-developers@googlegroups.com] > *Sent:* Tuesday, August 16, 2022 2:55 PM > *To:* Django developers (Contributions to Django itself) < > django-developers@googlegroups.com> > *Subject:* Re: More user friendl

RE: More user friendly delete confirmation template

rom: 'Adam Johnson' via Django developers (Contributions to Django itself) [mailto:django-developers@googlegroups.com] Sent: Tuesday, August 16, 2022 2:55 PM To: Django developers (Contributions to Django itself) Subject: Re: More user friendly delete confirmation template If the object to be d

Re: More user friendly delete confirmation template

> > If the object to be deleted contains many relations, the user > is overwhelmed with a list of other objects to be deleted together with the > current object. Often those objects are just internal relations the user > never heard of, and this may be unsettling. > I would argue that if the list

RE: More user friendly delete confirmation template

Hi Jacob. On the one side - you can override this delete_confirmation.html and delete_selected_confirmation.html I do it since dj 1.4 On the other side I am agree with Jacob - it can be in Django by default. – We can add “collapsed” div to wrap with every objects list, or we can add

Re: UI/UX - FilteredSelectMultiple - Filtering the selected options

Thanks Jacob. We have the functionality of the selects working fine, it's just finding a way to make it clear to the user that the selected options that are filtered out are still in fact selected and will be sent as such in the POST. Thanks for the info though, I'll take look. On

Re: UI/UX - FilteredSelectMultiple - Filtering the selected options

I'have implemented such a widget in django-formset . It just hides (removes) the selected options which have been filtered out. Otherwise, filtering by muting options, wouldn't have the desired visual effect. Please note that in order to implement this feature,

Re: Feature request: LiveServerTestCase to store HTML source and image of the website when test case fails

Hi Kazooie LiveServerTestCase is a bit more lightweight than tools for using specific drivers. It doesn't tie into Selenium, or Playwright, or any other particular web browser library. Therefore I don't think there's going to be any way for LiveServerTestCase to know what the current page is, in

Re: Django Hosting Service

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely

Re: Django Hosting Service

Hi Kalidas, If you just want to explore how to deploy a Django application for free without having to do all the server configurations, database setup on your own, try Heroku. If you want to deploy a production grade application and need fine grain control over the entire infrastructure, there

RE: Django Hosting Service

Hi Kalidas R, Check DigitalOcean, if I understood your question correctly. Best, Teklit From: django-developers@googlegroups.com On Behalf Of Kali Raja Sent: August 11, 2022 1:10 To: Django developers (Contributions to Django itself) Subject: Django

Re: Removal of USE_L10N setting

Starting with version Django 5.0, with USE_L10N setting being removed, will there be any way to control how date times look in the Admin site? Removing this setting makes scientific/engineering applications lose a lot of control in the admin interface. Say I have a field created_utc and it

Re: PivotTable or MDDataTable

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely

Re: Feature Request: New PostgreSQL ArrayField

Hello, thanks a lot for your answers. I am very embarrassed to say that I went a bit too fast in my testing of nested ArrayField, and it turns out that it actually fits my use case. def test_nested_array_accepts_1D_array(self): instance = NestedIntegerArrayModel(id=1, field=[1, 2, 3])

Re: Feature Request: New PostgreSQL ArrayField

Hi Liamine, I think there's various solutions you could try before going the custom field route: * You could try just using the 2D version and use some sentinel value for the date (NULL?) to treat the case where you just want an array of N prices. * You could try using django-polymorphic [1]

Re: Feature Request: New PostgreSQL ArrayField

Hello Liamine, Django offers a JSONField which can be used to store an array. You can use it to store a list of prices. What's the benefit of using an array instead of JSON? – Jacob -- You received this message because you

Re: Deprecate CICharField, CIEmailField, CITextField

As far as I'm aware you can use: CreateCollation("case_insensitive", "und-u-ks-level2", provider="icu", deterministic=False) to create a case insensitive collation on PostgreSQL. -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Deprecate CICharField, CIEmailField, CITextField

Since these are PotsgreSQL-specific fields that are being deprecated, might it make sense to provide a hint as to what the CreateCollation() call should be? I'm looking around and it's not immediately obvious. The CreateCollation() examples in Django are for a German phone book, where in

Re: Should SECRET_KEY be allowed to be bytes?

Years later, sorry. But this is still broken and SECRET_KEY management is a mess! Even though you can now use bytes, this line here will blow up if you attempt to use bytes as a secret key: https://github.com/django/django/blob/3.2.14/django/core/checks/security/base.py#L202 Basically, we are

Re: Fellow Reports - July 2022

Week ending July 31, 2022 *Triaged: * https://code.djangoproject.com/ticket/33866 - Support Path instances in GDALRaster constructor (accepted) https://code.djangoproject.com/ticket/33867 - Automatic detection of timezone in django admin using javascript (duplicate)

Re: timesince and timeuntil - should we use python-dateutil?

I'd suggest the docs are updated with a warning relating to what's Uri's found as it could be extremely important to someone and not highlighting it would be misleading . On Tuesday, 2 August 2022 at 16:31:33 UTC+1 Uri wrote: > Hi, > > I created my own utility function: > > > > *from

Re: timesince and timeuntil - should we use python-dateutil?

Hi, I created my own utility function: *from dateutil.relativedelta import relativedelta* *from django.utils.timesince import TIME_STRINGS as timesince_time_strings**from django.utils.html import avoid_wrapping* *from django.utils.translation import gettext, get_language*

Re: timesince and timeuntil - should we use python-dateutil?

Hi Carlton, I understand, thank you. Uri Rodberg, Speedy Net אורי u...@speedy.net On Tue, Aug 2, 2022 at 10:54 AM Carlton Gibson wrote: > Hey Uri. > > Historically, taking on extra dependencies isn't something we've done > lightly. > The packaging situation is a lot better these days than

Re: timesince and timeuntil - should we use python-dateutil?

Hey Uri. Historically, taking on extra dependencies isn't something we've done lightly. The packaging situation is a lot better these days than it was in earlier years, but with the concerns about supply chain security I think maintaining that position is worthwhile. If we were to take on

Re: Improvements to the startproject template

anies that use Django and I have seen >>>> that each ot them has their own structure of project. >>>> >>>> And usually project is created once per couple of months, so I don't >>>> see advantages of changing project structure. >>>> >>>&g

Re: Deprecate CICharField, CIEmailField, CITextField

https://code.djangoproject.com/ticket/33872 -- 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

Re: Deprecate CICharField, CIEmailField, CITextField

> Support for PostgreSQL 10 was dropped in Django 4.1, and support for PostgreSQL 11 was dropped in Django 4.2. When CICharField, CIEmailField, CITextField deprecation starts in Django 4.2 they will be removed in Django 5.1. -- You received this message because you are subscribed to the

Re: Switching to PEP 621 project metadata

On Mon, Jul 25, 2022 at 8:04 AM Ofek Lev wrote: > Can we please quantify such heuristics? I want something concrete to write > in my OSS to-do list :) > I don't think we can or should provide an exact number of other projects that need to adopt what you're doing before we will. It's more of a

Re: Switching to PEP 621 project metadata

Hey Ofek. On Mon, 25 Jul 2022 at 17:04, Ofek Lev wrote: > > I'd much rather let the bulk of smaller projects adopt, and iron out the > details, and then update when it's a better beaten track. > > Can we please quantify such heuristics? I want something concrete to write > in my OSS to-do list

Re: Switching to PEP 621 project metadata

Okay then! Just 2 questions before I go: > I'd much rather let the bulk of smaller projects adopt, and iron out the details, and then update when it's a better beaten track. Can we please quantify such heuristics? I want something concrete to write in my OSS to-do list :) > I am referring to

Re: Switching to PEP 621 project metadata

I agree with James and Carlton, -1 from me. Best, Mariusz -- 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

Re: Fellow Reports - July 2022

Week ending July 24, 2022 *Triaged: * https://code.djangoproject.com/ticket/33854 - dbshell additional parameters should be passed before dbname on PostgreSQL. (accepted) https://code.djangoproject.com/ticket/33855 - System check calls are unnecessary in test worker initialization.

Re: Switching to PEP 621 project metadata

I think we need to be very cautious. Anecdotally, I've seen folks hitting issues trying to adopt the new methods, and I don't see any upside to Django being an earlier adopter here. We were slow adopting PEP 517 and still had regressions reported: https://github.com/django/django/pull/12013

Re: Switching to PEP 621 project metadata

On Sun, Jul 24, 2022 at 1:34 PM Ofek Lev wrote: > > My initial reaction is "no", and that this request kind of rubs me the > wrong way. In the pull request you say [...] But the blog post you quote is > just saying to run "python -m build" instead of "python setup.py" > > This issue is that the

Re: Switching to PEP 621 project metadata

> My initial reaction is "no", and that this request kind of rubs me the wrong way. In the pull request you say [...] But the blog post you quote is just saying to run "python -m build" instead of "python setup.py" This issue is that the `python -m build`/PEP 517 way does not support the

Re: Switching to PEP 621 project metadata

On Sun, Jul 24, 2022 at 10:06 AM Ofek Lev wrote: > Hello! This is about using only `pyproject.toml` for packaging > https://github.com/django/django/pull/15874 My initial reaction is "no", and that this request kind of rubs me the wrong way. In the pull request you say: > As a result, the

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'll drop it. Someone else can chime in if they want. Just to be clear, the work you all do on Django is much appreciated :) Thanks, Dave On Thursday, July 14, 2022 at 6:53:41 PM UTC-5 James Bennett wrote: > On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert wrote: > >> Yeah, I hope I'm not coming

Re: Fellow Reports - July 2022

Week ending July 17, 2022 *Triaged: * https://code.djangoproject.com/ticket/33837 - 中文版文档：编写你的第一个 Django 应用，第 3 部分中的描述性代码错误 (invalid) https://code.djangoproject.com/ticket/33835 - Select_related().only() in the Prefetch() should automatically add primary keys for reverse relations.

Re: Features deprecated in 4.1 / Log out via GET

Hi Adam, Just for the record, if anyone is seeing this thread - what works for me is running tests with "python -W error" (and not "python -W all") so that all the warnings are converted to exceptions - then the tests fail. If I run them with "python -W all" I can see the warnings but the tests

Re: Feature Request: New parameter for render_to_string() to render part of a template using a selector

I’m also -1. There are many ways to “partially render” a template. I covered one in the Django-htmx docs mention one: https://django-htmx.readthedocs.io/en/latest/tips.html#partial-rendering . The proposal to render the full template and then throw away most of the result is a particularly

Re: Feature Request: New parameter for render_to_string() to render part of a template using a selector

I'm going to chime in as a -1 here. It does not seem to me that you can guarantee that you have the correct element(s) unless you actually render the complete template. Once you've rendered that template, then you can use tools like BeautifulSoup to extract the elements desired and ignore

Re: Feature Request: New parameter for render_to_string() to render part of a template using a selector

Don't you have to render the template in the first place if you want to extract a fragment of it? If that's the case then shouldn't render_to_string be left unchanged and libraries interested in this feature build something on top of it to achieve what they're after? Given render_to_string is

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert wrote: > Yeah, I hope I'm not coming off as being too pushy, but I'm just curious > why that is. Mariusz or Adam, did what I said about it being *more* than > just an alias for `filter().first()` make sense or am I missing something? > (Different

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

> I'm not the first to suggest adding an additional shortcut, e.g. django.shortcuts.get_object_or_none which would work similarly to get_object_or_404 Personally I'm not a fan of it being in "shortcuts". It makes sense to me that the 404 ones are there because they are only useful in a

Re: database column order

charettes - Tue, 12 July 2022 at 13:11:14 > If you add fields to one your existing models the migration framework will > add them at the end of your table as that's the most straightforward way of > doing so. Of the top of my head only MySQL supports a syntax to add a is it a correct takeaway,

Re: database column order

I agree with Simon here. I don’t think Django should account for postgres column order, especially when there’s no way to change column positions other than by rebuilding the table. By the time you have enough data for the space savings to be valuable, you probably need to use a careful strategy

Re: database column order

Foreign keys are added at the end in cases where there are reference cycles between models that must be broken. Instead of creating the column first and then creating the foreign key constraint the migration framework opted to combine both operations as it simplifies a few things. If you add

Re: Fellow Reports - June 2022

Week ending July 3, 2022 *Triaged: * https://code.djangoproject.com/ticket/33809 - ValueError in migrations using apps.get_model() for a ForeignKey. (needsinfo) https://code.djangoproject.com/ticket/6904 - Dictsort filter should sort case insensitive (wontfix)

Re: __slot__ like behaviour for Model classes?

I realize this thread is 15 years old, but I actually ran into this issue the other day. I was running a custom migration with a RunPython function, where rather than typing: my_model.message = '...' I accidentally wrote: my_model.mesage = '...' The migration ran successfully, so I ended up

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hi I believe the main objection is against adding additional API to querysets. get_object_or_404 only converts DoesNotExist into a 404 exception and doesn't handle MultipleObjectsReturned. I'm not the first to suggest adding an additional shortcut, e.g. django.shortcuts.get_object_or_none which

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Fair enough. To me, the `get_or_none` behavior with multiple results would still be to raise an exception (so it is just like `get` in that sense). And that’s the reason I personally don’t just see it as a shortcut for `filter().first()` — I have (as I’m sure others have) made the mistake

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'm also against adding get_or_none(), for the same reasons. Adding a method to shortcut something that can already be done doesn't seem worth it to me. On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak wrote: > I'm against it because it's already easily achievable and it's debatable > how it

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'm against it because it's already easily achievable and it's debatable how it should behave with many results. IMO any new method would be confusing and in the case of unique filtering `get_or_none(unique_filters)` would be an alias for `.filter(unique_filters).first()`. To me, this is

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hey Mariusz, thanks for the link — I found some other threads but not that one. Would you mind saying why you're personally against it (`get_or_none` specifically)? At least how I read that thread, there was more debate about how to add it than whether to add it at all, and then Cal sort of

Re: Adding a script positional argument to dbshell

Hi dbshell already passes all unknown arguments through to the underlying program. For example on postgres you can use the psql '-c' option like so: $ ./manage.py dbshell -c 'select 123' ?column? -- 123 (1 row) argparse allows a -- separator to split arguments for dbshell and the

Re: Hello everyone! Guide me in this journey.

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hi, Adding `get_or_none()` was discussed several times and was always rejected. This thread has a nice summary. Personally, I'm still against it. Best, Mariusz -- You received this message because you are

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'm new to this... anybody know how the best way to push this forward? Or who can make a decision on whether something could/should be added to Django? I see some other tickets/discussions about basically the same thing: https://code.djangoproject.com/ticket/17546 A lot has changed in 10+

Re: RE : Email on App

Indeed this is the wrong mailing list. For support not just on email, you can follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to

Re: RE : Email on App

Hi Arun, This is the wrong mailing list to ask this question. This is the mailing list for the actual development of django. Instead, I think you are looking for django-users mailing list. Cheers. El dl., 4 de jul. 2022, 22:47, Arun va escriure: > Hai , > > i am have requirement , user need

<    4   5   6   7   8   9   10   11   12   13   >