Re: Escaping of JSON attributes and CVE-2024-42005

Hello Ole, this was discussed during the security enforcement patch design but wasn't part of the public announcement unfortunately. The solution is to alias a KT[0] expression and then filter against it. In you particular example that would be from django.db.models import KT SomeModel.objects

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

Hello Akash, Another approach that isn't mentioned here but alluded to in the ticket is to actually move bulk_update away from using Case / When which is the root of the issue here. We know that using Case / When is slow

Re: Ticket #30382 force_insert flag is not passed when saving parents on inherited models

sert, > > force_update is currently the opposite of force_insert. Would/should > force_update accept the same pattern? > On Friday, 19 May 2023 at 06:15:00 UTC+2 charettes wrote: > >> I left some notes on the PR but I think the crux of the issue here is >> that y

Re: Ticket #30382 force_insert flag is not passed when saving parents on inherited models

I left some notes on the PR but I think the crux of the issue here is that you are trying to change the meaning of Model.save(force_insert=True) from force the insert of the current model to force the insert of the model and all its bases. This is a problem not only for QuerySet.create but like

Re: Ticket #34555 ModelBase prevents addition of model Fields via __init_subclass__

Just wanted to publicly +1 here as well. I was skeptical that we could add support for it without invasive changes at first but it seems to be relatively straightforward to support. One ask I would add is that we explicitly document what is support and what isn't. For example, at the time `__in

Re: Oracle 23c released earlier this month

Thanks for sharing the news David! Support for true BOOLEAN type and GROUP BY position are effectively very welcome changes as they account for a few hacks. I do wonder if that's paving the way for grouping by subquery in future versions. Best, Simon Le lundi 17 avril 2023 à 08:06:57 UTC-4, Ma

Re: Implement Ruff Linter

Strong agree with Adam here. If Ruff current offer is enhanced speed at the cost of a less mature ecosystem I don't think that it's a tradeoff Django should make at the time being. Simon Le jeudi 6 avril 2023 à 08:16:00 UTC-4, Adam Johnson a écrit : > I don't think we should adopt Ruff. It's

Re: Proposal: Check constraints at the model field level

Small clarification here. > it should be noted that SQL has both CHECK on the field and table level, >From my understanding CREATE TABLE / ADD COLUMN checks on the field level are really just syntactic sugar for checks at the table level like just like `REFERENCES` usage is syntactic sugar for

Re: GSOC 2023 Discussion and Feedback: Database-level Cascades

The difficulty of switching to database level constraint effectively resides in how your lose the great parts of cascade deletion emulations most notably signals post and pre-delete signals. If you're willing to make this compromise then you must make sure that all cycle of model relationships

Re: PermissionRequiredMixin not importable before apps ready?

Hello Christian, Could you possibly provide a minimal project setup that reproduces your issue? >From what I can see here you're running into this issue because the `django.contrib.auth.views` module calls `get_user_model` at initialization time but the latter has been passing `require_ready=F

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

he near future at a Django event once we get more feedback about it. [0] https://github.com/charettes/django-syzygy Cheers, Simon Le mardi 29 novembre 2022 à 04:41:49 UTC-5, ator...@redhat.com a écrit : > I'd personally like to see better support for safe / N-1 compatible > migrat

Re: Technical Board vote on DEP 0012: The Steering Council

+1 from me as well. Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit : > Hi All. > > Tom Forbes is currently unable to post to the Google Group here, due to > Currently Undiagnosed Google Account Weirdness™. > > For the record he's asked me to say that his vote is +1 in

Re: Advancing the "content negotiation" and "modernising request object" proposals.

rted Media Type response. > > DRF’s behaviour feels more correct to me, since it allows terser views > that don’t check the content type explicitly. But it’s less backwards > compatible. I’m not sure which I prefer. > > On Thu, Nov 10, 2022 at 3:14 AM charettes wrote: > >>

Re: Advancing the "content negotiation" and "modernising request object" proposals.

Hello Carlton, This is not an area of the code base I'm heavily involved with but the increment approach you are proposing over this lack of feature support for basic content negotiation seems like a sane approach to gradually make the landscape better in this area without trying to get everyth

Re: help needed in #33586

Hello Bhuvnesh, I tried to provide some guidance on the ticket . I know you are eager on getting help but please allow for a few non-weekend days before elevating your request for support as most of us are volunteers here. Cheers, Simon

Re: UniqueConstraint validation error message conditional vs non-conditional

> -- >> Traceback (most recent call last): >> ... >> AssertionError: {'__all__': ['Constraint “name_without_color_uniq” is >> violated.']} != {'name': ['Constraint

Re: UniqueConstraint validation error message conditional vs non-conditional

would be preserved. > > This also leads to another question I had about whether it might be an > idea to allow overriding error messages for constraints in forms using the > error_messages dict… but I'll leave that for another post :) > > Regards, > David > >

Re: UniqueConstraint validation error message conditional vs non-conditional

Hello David, This is expected because Django doesn't have a way to express the constraint in words to present to the user when a condition, which could be complex, is provided. When no conditions are defined the metadata is easy to interpret to form a sentence out of ("Foo with this field0, fi

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 addi

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 c

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 fi

Re: Generated Field

> Is it necessary to take a base field? Can we not determine the output field type for some kinds of expression? e.g. F("some_integer_field") + 1 can be assumed to have output field type IntegerField. It should be possible by simply accessing the `output_field` property of the provided expressi

Re: Splitting tests instead of testcases by processors when parallelizing tests

The main drawback will be that won't be able to take advantage of setUpTestData to perform costly data creation _once_ for all the tests attached to the same TestCase. Splitting the suite per test will likely force setUpTestData to be called once per process that has at least once one test of t

Re: Newer constraint declarations and Foreign Keys

If you're interested in following the development of the database level foreign key constraints feature you should CC to #21961 [0] The latest attempt at implementing them was recently closed due to inactivity [1] Cheers, Simon [0] https://code.djangoproject.com/ticket/21961 [1] https://github

Google Group's django-updates issue

Hi everyone, I'm not sure if we're already aware of the issue but it seems that Trac hasn't published any changes to the Django Updates Google Group[0] since March 27th while there was clear activity that took place since then[1]. It seems the updates were published over SMTP[2] and I assume so

Re: Combining multiple aggregations with annotate()

While addressing the issue is complex and will require quite a bit of work to solve in a backward-compatible way I believe that it should be feasible to emit a MultipleMultiValuedJoin(RuntimeWarning) with pointers for alternatives (e.g. using subqueries) without too much hassle when aggregation

Re: [TB] Proposal to add Florian Apolloner to Releasers team.

I'm also +1 Le mercredi 21 juillet 2021 à 17:21:03 UTC-4, Adam Johnson a écrit : > +1 I’m in favour of giving Florian the access and necessary training, > should he want it. > > On Wed, 21 Jul 2021 at 10:18, Carlton Gibson wrote: > >> Hello Technical Board. >> >> Mariusz is working on updating

Re: `Model.validate_unique` excluding partial unique constraint

fter > all. > > Le mercredi 7 juillet 2021 à 20:53:23 UTC+2, charettes a écrit : > >> Just a small note that I didn't forget about this thread but I was >> waiting for lookup annotation support to land before focusing on it[0]. >> >> I guess you could go ahead

Re: `Model.validate_unique` excluding partial unique constraint

; > https://github.com/Gagaro/django/commit/cfd10066359c175179ae937a287eb9f0240354f1 > > Le mardi 22 juin 2021 à 16:43:36 UTC+2, charettes a écrit : > >> > I don't like using raw SQL when there is a better way to do it (is >> there?). >> > And it doesn'

Re: `Model.validate_unique` excluding partial unique constraint

raw SQL when there is a better way to do it (is there?). > And it doesn't work when used in the Exists as the table is aliased and > the raw SQL is not. > > Do you have any idea how to fix/improve that? > > Thanks again! > > Le lundi 21 juin 2021 à 18:00:03 UTC+2, charette

Re: `Model.validate_unique` excluding partial unique constraint

That's looking great :) 1. Yes and that's expected. If a form/serializer doesn't provide some fields included in the constraint the database client side of the validation can't do much about it. It might result in an integrity error but that's a misuse of the API. I guess a check/runtime warnin

Re: How can I make testcase for new migration feature (DB Comment) #18468

Hello there, I confirm that you'll have to adapt get_table_description for each supported backends to introspect column comments. It seems that introspection support was considered to be a requirement for this ticket[0]. Not sure if that means that the inspectdb logic also needs to be adapted

Re: `Model.validate_unique` excluding partial unique constraint

gt; Should we still add Q.check() (which will be as you said before), then > refactor BaseConstraint.validate() to use it? > > Le mercredi 16 juin 2021 à 02:04:31 UTC+2, charettes a écrit : > >> I meant 1. in my previous email where sql.Query.model is allowed to be >> None. The t

Re: `Model.validate_unique` excluding partial unique constraint

I meant 1. in my previous email where sql.Query.model is allowed to be None. The tests happen to pass on SQLite, MySQL, and Postgres. Le mardi 15 juin 2021 à 20:02:28 UTC-4, charettes a écrit : > FWIW I thought I'd give a timeboxed shot at 2. to make sure I don't send > yo

Re: `Model.validate_unique` excluding partial unique constraint

> Thanks, it clears things a lot. > > I'll try my hand at it when I'll have some more time available. > > Le jeudi 10 juin 2021 à 06:00:17 UTC+2, charettes a écrit : > >> Alright so here's for a few hints about I believe things should be done. >>

Re: `Model.validate_unique` excluding partial unique constraint

> the models to do something without one. > > If you have any more hints as to where I should look, thanks again. > Le mercredi 2 juin 2021 à 00:33:12 UTC+2, charettes a écrit : > >> Hello there, >> >> Partial unique constraints are currently not support

Re: `Model.validate_unique` excluding partial unique constraint

Hello there, Partial unique constraints are currently not supported during validation for reasons described in this ticket[0]. For example (inspired by this Github comment[1]), if you define the following model class Article(models.Model): slug = models.CharField(max_length=100) delete

Re: Transaction APIs do not consult the DB router to choose DB connection

yErrors) 2. It's just not common enough to warrant an inclusion in Django core. Every single added feature comes with a maintenance burden cost and risks introducing bugs when interacting other existing features. This is particularly true with niche features interacting with complex sy

Re: Transaction APIs do not consult the DB router to choose DB connection

Ticket that directed to the mailing list for wider feedback https://code.djangoproject.com/ticket/32788 --- Can you think of places where this db_for_transaction hook would differ in any way from what db_for_write returns? That's what Django uses internally in such instances 1. ​ https

Re: "Unify by values" setting in Oracle's base.py

iable would normally > be included in both the SELECT list and the GROUP BY. > > Regards, > Nigel > > On Monday, 5 April 2021 at 15:45:31 UTC+1 charettes wrote: > >> Hello Nigel, >> >> Through git blame for unify_by_values I figured it was introduced[0] to &g

Re: GSOC Proposal : Adding a Redis cache backend to Core

Hello Daniyal, > I want to move ahead with using the pickle module. However, does it seem necessary to add support for other serializers ( json / yaml / msgpack ) as well? I don't think that adding support for configurable serialization is necessary for this project. Don't get me wrong, I thin

Re: "Unify by values" setting in Oracle's base.py

Hello Nigel, Through git blame for unify_by_values I figured it was introduced[0] to deal with an issue during aggregation[1]. Mariusz might be able to provide more context here as I don't have much knowledge around Oracle cursor cache but it seems you'll have to find another way to address th

Re: Increase default integer keys to 64 bits

As Tom said Django 3.2 supports swapping the default primary key of models so the integer exhaustion part of your suggestion should be addressed Regarding identity columns support there's already a ticket opened about it on Trac[0] where you might want to chime in. Even #30511 if doesn't land i

Re: Update returning

If we were to change the update signature from (**updates) to (updates=None, *, returning=None, **kwargs) the `returning` collision could be avoided by doing update({"foo": "bar"}, returning=["id", "foo"]) like Tom is suggesting. I think that's the best option here if we want to elegantly add s

Re: #28560 - distinct() on ordered queryset with restricted list of columns returns incorrect result

I'm also a fan of option 3. to require an explicit opt-in or raise an error. Not a lot of folks are familiar with this requirement imposed by the usage of DISTINCT and even if Model.Meta.ordering is the most common reason but unexpected ordering it can also be caused by the dynamic creation of a

Re: Advancing with the Triage & Review Team idea.

I like the idea but I don't feel comfortable vouching for it given my conflict of interest. I'll just say that It does feel weird that folks on this list which are the main active contributors outside of a few members of the currently elected TB don't have access to basic triaging and reviewing

Re: The cotent types framework unreasonably limits model name length.

> Suffix-hashing long names like Simon suggests may not be backwards-compatible. Could you elaborate on that? Assuming model names > 100 characters never worked wouldn't only suffix-hashing model names > 100 characters be backward compatible? Simon Le mardi 11 août 2020 à 12:05:46 UTC-4, Sha

Re: The cotent types framework unreasonably limits model name length.

I agree this limitation of `contrib.contenttypes` is a bit unexpected. Not saying we should lift it but it does seem arbitrary even if having such large table names could be considered bad practice. One approach we could take that doesn't involve any migration is to fallback to hashing of the o

Re: FK field caching behavior change between 1.11.x and 2.x

is > surprising and buggy at face value: changing the value of an attribute on > one object should not change the value of that attribute on another! > > Alex > > On Wed, Aug 5, 2020 at 7:43 AM charettes wrote: > >> It was likely overlooked by the patch. >> >&

Re: FK field caching behavior change between 1.11.x and 2.x

;. > > Cheers > > On Tue, 4 Aug 2020 at 15:52, charettes wrote: > >> Hello Gert, that seems a bit surprising to me and was likely not a >> desired change. >> >> Could you bisect the exact commit that caused the regression[0]? That >> would certainly h

Re: FK field caching behavior change between 1.11.x and 2.x

Hello Gert, that seems a bit surprising to me and was likely not a desired change. Could you bisect the exact commit that caused the regression[0]? That would certainly help determining the action to take here. Thanks, Simon [0] https://docs.djangoproject.com/en/3.1/internals/contributing/tri

Re: Status of 3.1 release blockers.

I like the state of your proposed PR Mariusz. It does add one more setting but it feels like having this configurable project wide will be a plus as it will allow the ecosystem to rely on it and hopefully make audit of large Django application a bit easier when having specific hashing requiremen

Re: Custom collation support

own its review and affect its mid-term mergeability. >> > > Yes, it is probably best to extract the operations to another ticket/PR. > > On Mon, 20 Jul 2020 at 03:48, charettes wrote: > >> Thanks for your work so far Tom! >> >> > There is perhaps some scope i

Re: Custom collation support

Thanks for your work so far Tom! > There is perhaps some scope in the future to make this take a callable that can figure out the collation per-database. This would be useful for getting case-insensitive lookups working across all backends, for example. But I want to keep that out of the scope

Re: Feature request: Possibility to declare transactions as read only

Hello Andor, I think it would make sense to add this feature to Django but I'm not convinced per-atomic block granularity is the best API to expose this rarely used pattern. For example, how should this option behave when nesting atomic block and mixing readonly values or disabling usage of sa

Re: Defaulting to use BigAutoField in models

mary key they use for their model but I'm not a big fan of baking logic in the migration framework to treat some fields in a special way. Simon Le jeudi 18 juin 2020 10:18:35 UTC-4, charettes a écrit : > > +1 from me as well but I don't think we should add any logic to the &g

Re: Defaulting to use BigAutoField in models

+1 from me as well but I don't think we should add any logic to the migration framework to handle the transition. I think the release plan should be something along the following Phase 1: - New projects are generated with MODEL_DEFAULT_PK = 'django.db.models.BigAutoField' - A system check or wa

Re: queryset.iterator() and prefetch_related()

The code could possibly be removed if the PR gets merged in time for 3.2 yes. Le jeudi 11 juin 2020 09:44:32 UTC-4, 1337 Shadow Hacker a écrit : > > Well that's good to know, thank you charettes ! > > Does that mean that the piece of code from forms that's using "priva

Re: queryset.iterator() and prefetch_related()

FWIW there's ungoing work to allow iterator() to use prefetch_related() which would allow us to lift this restriction. See https://groups.google.com/forum/#!searchin/django-developers/iterator$20prefetch%7Csort:date/django-developers/ADgUd6jRvdw/_ZnETNlcAAAJ Cheers, Simon Le jeudi 11 juin 2020

Re: What happens if a Fellow has a holiday?

Happy to review help as well. Enjoy your well deserved time off! Le jeudi 4 juin 2020 06:47:57 UTC-4, Carlton Gibson a écrit : > > Hi all. > > Short answer is we don't really know, since we never take holidays. 🙂 > > I though am having a much needed week off from tomorrow, to be back on the > 1

Re: QuerySet.iterator together with prefetch_related because of chunk_size

g, and also favour option 2 now, especially >>> since the default can break on sqlite. >>> >>> It would also be possible to go through a deprecation period to first >>> raise a warning and not prefetch, before a later version raises an >>> exception, which i

Re: Django Version 3.2 Roadmap

Proposal looks good to me. +1 to moving to the 6th of April, I remember it caused a bit of confusion in the past and we should avoid that particularly for a LTS release. Thanks Carlton. Le mercredi 13 mai 2020 11:08:18 UTC-4, Markus Holtermann a écrit : > > Hi Carlton, > > thank you. The propo

Re: [FEATURE] Allow squashmigrations to squash the whole project

`known_third_party` packages. > https://github.com/timothycrosley/isort#configuring-isort > > At least I was under the impression that that's the only way how it > decides where to place imports. > > Cheers, > > Markus > > On Tue, Apr 28, 2020, at 9

Re: [FEATURE] Allow squashmigrations to squash the whole project

O:) > > On Apr 28, 2020, at 2:29 PM, charettes > > wrote: > > Don't we need to prevent that from happening anyway? I guess we'd want to > prevent --crossapp=auth from working as well. > > Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit : >>

Re: [FEATURE] Allow squashmigrations to squash the whole project

Don't we need to prevent that from happening anyway? I guess we'd want to prevent --crossapp=auth from working as well. Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit : > > To do that we need to know which apps are part of your project, and which > are not. Otherwise you'll be squas

Re: [FEATURE] Allow squashmigrations to squash the whole project

I guess we could allow an "__all__" or "all" sentinel to mean _all apps_ like we use "zero" to revert the initial migration. Le mardi 28 avril 2020 12:16:23 UTC-4, Javier Buzzi a écrit : > > And then do? > > $ ./manage.py squashmigrations --crossapp=$(find . -name apps.py | sed > 's|/apps.py$||;

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

I'm also -1 on removing the form field for the same reasons as Adam. Le vendredi 24 avril 2020 06:39:06 UTC-4, Mariusz Felisiak a écrit : > > `models.NullBooleanField` is now deprecated [1]. > > I would like to ask again about opinions on deprecating `forms. > NullBooleanField` because I'm not con

Re: Technical Board statement on type hints for Django

Thanks for sharing your answer publicly Adam and Markus. Here are the points I brought up in the discussion >From my limited experience with type annotation on a large monolithic code > base that was ported from Python 2 to 3 even gradual typing has been a lot > of trouble for the few benefits

Re: New Merger nomination.

I cast my vote in favor of Claude's nomination as well. Le jeudi 16 avril 2020 16:16:31 UTC-4, Adam Johnson a écrit : > > This has fallen by the wayside, let's try restarting. > > As Carlton points out, Claude hasn't been merging in code without others > reviewing it. But as I understand it is us

Re: Proposal to not implicitly create varchar/text-pattern opclass indexes on PostgreSQL

Makes we wonder under which circumstances an OAuth token would need to be looked up using LIKE. I would expect the unique b-tree index which covers exact lookups to be sufficient. Simon Le mardi 14 avril 2020 09:01:48 UTC-4, Adam Johnson a écrit : > > For some numbers: I just checked on a long-

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

For the record a PR doing exactly that has been reviewed and merged already and should be of 3.1 https://github.com/django/django/pull/12627 Cheers, Simon Le lundi 6 avril 2020 13:54:27 UTC-4, Florian Apolloner a écrit : > > > > On Thursday, March 12, 2020 at 6:16:31 PM UTC+1, Dawid Czeluśniak

Re: Filtering window expressions. Ticket #28333

'(%s)' % sql > return sql, params > > If someone is willing to discuss ideas about the process, please reach out > to me. Devil lies in the details, and I suppose some > of the problem that subqueries are difficult in the ORM could be mended > with work on this pa

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

I agree with Adam here, it not just about running the SQL itself; the current migration framework require models to be (re-)rerendered before a lot of schema operations which slows down dramatically as project grows. The dump/restore approach will undeniably be faster than running migrations fo

Re: GSoC 2020 Proposal for ModelStates in Migrations

arification/explanation would be highly helpful. > > Kind regards > Sanskar > > On Fri, Mar 27, 2020 at 8:11 AM charettes > > wrote: > >> Thanks for the examples Sanskar. >> >> I think the mapping should be kept ProjetState instances and invalidated >>

Re: GSoC proposal research - type hinting

You might also be interested in this Django Enhancement Proposal to add type hints to Django https://github.com/django/deps/pull/65 Cheers, Simon Le vendredi 27 mars 2020 19:08:07 UTC-4, Kacper Szmigiel a écrit : > > Hello everyone! > > My name is Kacper, I'm 22 y.o. CS student from Lodz, Polan

Re: GSoC 2020 Proposal for ModelStates in Migrations

r we run > makemigrations. Do you have a better idea? > > Thanks! > Kind Regards > Sanskar > > On Thu, Mar 26, 2020 at 6:05 AM charettes > > wrote: > >> Thanks Sanskar, this iteration is much better. >> >> Now that you have a bit more details ab

Re: GSoC 2020 Proposal for ModelStates in Migrations

> Sanskar > > > > On Wed, 25 Mar 2020 at 23:57, charettes > > wrote: > >> Are you thinking about the Operation.state_forwards logic? I guess it >> would make it easier to test state alterations in isolation but I don't >> think it's necessary f

Re: GSoC 2020 Proposal for ModelStates in Migrations

; >> Hey Simon, >> >> Thank you for your feedback! It helps a lot. I shall look into your >> doubts right now, and edit my proposal accordingly. >> >> Kind regards >> >> Sanskar >> >> On Tue, Mar 24, 2020 at 3:37 AM charettes > > w

Re: GSoC Mentors

I confirm my willingness to be a mentor for ORM and Migrations related work. Simon Le mercredi 25 mars 2020 04:43:49 UTC-4, Carlton Gibson a écrit : > > Hi all. > > We're reaching the end of the application period for GSoC. > > In order to know how many students we might accept, we need to know

Re: GSoC 2020 Proposal for ModelStates in Migrations

Hello Sanskar, Thank you for your submission, from a quick look it seems to be heading in the right direction. Would it be possible to break the large overview section into more granular sections where you describe how you roughly plan to tackle each of the point mention? I personally have do

Re: GSoC 2020 Proposal for ModelStates in Migrations

Javier > I don't see how this solves anything. At the end of the day these "real" models, or at the very least, not "fake" models will not have any custom queryset/manager/properties/ method you add to it. Can you explain what it is you're trying to accomplish? I don't think that's the goal of

Re: TestCase.setUpTestData in-memory data isolation.

o see this feature included in the next versions of Django. Cheers, Simon [0] https://code.djangoproject.com/ticket/31395#ticket [1] https://github.com/charettes/django-testdata Le vendredi 23 novembre 2018 22:29:33 UTC-5, charettes a écrit : > > Dear developers, > > Django 1

Re: Request to reconsider #30311 -- allow overriding site-wide admin actions

want to > handle that too? 🤔 > > Cheers. > C. > > On Wednesday, 18 March 2020 17:53:29 UTC+1, Shai Berger wrote: >> >> (sorry about the previous empty mail, UI glitch) >> >> On Wed, 18 Mar 2020 09:29:17 -0700 (PDT) >> charettes wrote: &g

Re: Request to reconsider #30311 -- allow overriding site-wide admin actions

Just to make the above clear, here's what I had in mind https://gist.github.com/charettes/a0cb94242ac9c198625b23f4f55fab45 Le mercredi 18 mars 2020 12:20:54 UTC-4, charettes a écrit : > > Given the common need to override delete_selected I wonder if we could > define it as ModelAd

Re: Request to reconsider #30311 -- allow overriding site-wide admin actions

Given the common need to override delete_selected I wonder if we could define it as ModelAdmin method and use a .actions string reference to it in the AdminSite instead[0]. That would allow admin classes to simply override the delete_selected method on their admin classes without having to reso

Re: New Merger nomination.

I second this nomination. Le vendredi 13 mars 2020 15:30:19 UTC-4, Mariusz Felisiak a écrit : > > I nominate Claude Paroz to a new MERGER for 8 years of contributions to > Django, including triaging tickets, reviewing PRs, and serving as the > Django translations manager. Claude is one of the mo

Re: Rename salt to mask in CSRF

I think it's a non-invasive worthwhile change and that a PR for it would be well received. Le mercredi 19 février 2020 11:13:15 UTC-5, Ram Rachum a écrit : > > In any case, if it's decided that it's a worthwhile change, I'll be happy > to make the patch. > > On Wed, Feb 19, 2020 at 10:31 AM Adam

Re: Improve migration conflict detection

+1 to what Tim said. Also what about migration leaf migrations with models that refer to each others? What about a model rename in a leaf node that a model in the other leaf references to for some attribute names (e.g. m2m field intermediary table name). I don't want to discourage you from try

Re: Enhancement to assertQuerysetEqual

Hello Peter, I've always felt the current behaviour of assertQuerysetEqual was weird and always wondered why it was not implement the way you suggest. I think you're approach is clever and I can't think of a way it would break backward compatibility except if .values_list('charfield', flat=True

Re: Potential performance related bug in django`s Queryset.get().

Hey there! The current code assumes that .get() will likely match one result which should be the case most of the time and limit the number of possible results to prevent catastrophic matches Your patch has the side effect of performing an additional COUNT query for every single QuerySet.get()

Re: Stop QuerySet repr from executing queries

I agree with what James eloquently said, the issue is more complicated it appears. Simon Le mardi 15 octobre 2019 05:59:27 UTC-4, James Bennett a écrit : > > This request is a bit more complicated than I think people > realize. There's no practical way I can see to have the __repr__() of > a Que

Re: Logging in management commands

Hello Christian, I don't have an exact answer for you but there's open tickets about making management commands use logging instead of custom output wrappers that might interest you. Simon [0] https://code.djangoproject.com/ticket/21429 [1] https://code.djangoproject.com/ticket/27877 Le samed

Re: Discussing potential QuerySet.subquery interface

Hello Alexandr, I agree with Anssi and you that adding a method to perform a subquery pushdown would be useful. FWIW #24462 and #28333 are not the only tickets where that was proposed as a solution. Searching for "subquery" and "pushdown" should bring a few other tickets. There are also intern

Re: When filtring on a subquery expressions, the subquery appears twice in the SELECT and the WHERE

Hello Haki, This should probably have been posted to the django-users list given this one is for the development of Django itself but since there has been some recent and ungoing development in this area I'll reply here. First there has been work to reuse annotation aliases that is in the maste

Re: Add logging to related descriptors

ge of select_related and prefetch_related. One thing to note is that the package is still opt-in in the sense that it requires sealing querysets but we're thinking of adding a setting that enables it by default for all models. Cheers, Simon [0] https://github.com/charettes/django-seal

Re: Faster Migrations! But at what cost?

Hello Raphael, > Have there ever been any surveys about how the size of Django projects? I don't know the value of investigating this further except for our own usage. I'm not aware of any similar surveys in the recent years but I would say *240 models across 90 apps, with roughly 500 migration

Re: Proposal to format Django using black

I feel like it would be worse as it would break formatting changes across multiple commits, creating an inconsistent formatting code base and generating large unrelated changes diff when altering a still untouched file which would make the review harder. Cheers, Simon Le mardi 16 avril 2019 10:

Re: Proposal: make ForwardManyToOneDescriptor.get_object raise self.RelatedObjectDoesNotExist

As I've said on the ticket I think we should make this change as it's backward compatible and more coherent with the other RelatedObjectDoesNotExist usages of the related fields API. Cheers, Simon Le mardi 16 avril 2019 07:22:52 UTC-4, David Beitey a écrit : > > This continues the discussion from

Re: Proposal to format Django using black

gt; Hi Simon, > > On Monday, April 15, 2019 at 1:02:49 AM UTC+2, charettes wrote: >> >> and there's no way to turn off only this form of string normalization, >> it's all or nothing. >> > > So the black --help output lists: > -S, --skip-string-normal

Re: Proposal to format Django using black

I was and and I'm still bugged by how black decided to go for double quotes instead of single ones. Even if it's backed some valid arguments it left all the projects following PEP 8's recommendations over the years with this git blaming loss trade off. From past experimentation with large'ish p

  1   2   3   >