Re: Makemigrations hooks for third-party apps?

A bit late, unrelated: what is the reason behind not having django just add the extension `HStoreExtension` when it detects `hstorefield`? From what i can see, there there is a `create .. if not exists` on the sql command, and seems like a no brainer. Thanks On Wednesday, June 7, 2017 at

Re: Issue with multiple database backends

Ticket created https://code.djangoproject.com/ticket/32653#ticket Thank you On Wednesday, April 14, 2021 at 7:35:22 AM UTC-4 Shai Berger wrote: > Hi, > > On Wed, 14 Apr 2021 12:10:56 +0100 > "'Adam Johnson' via Django developers (Contributions to Django > itself)" wrote: > > > Hi > > > > This

Issue with multiple database backends

I have a model with a really long name think `ThisIsAReallyLongModelNameThatIsAlsoVeryOld`. To complicate things further I have a Oracle instance without archival data designated connection name `old` and a new postgres instance with the connection name `default`. Issue i've found is that if i

Re: queryset.values() / GROUP BY

This looks like a cool little side project. I would keep it there, the use case is very limited. I've always seen the django ORM as a very basic > On Jul 21, 2020, at 12:46 PM, René Fleschenberg wrote: > > Hi, > > on IRC, someone hinted me at https://github.com/kako-nawao/django-group-by >

Re: f-strings again.

I'm +1 f-string -- very conformable, easy to work with, and fits 99% of my needs. I'm -1 removing .format() -- there are some limitations to f-string, for example using them for a template-like placeholder/i18n, in these cases .format() comes very handy. Yes, I suppose %-format in these

Re: HttpResponse headers interface

All this makes a lot of sense. -- 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: HttpResponse headers interface

@Tom looks great, should we add depreciation notices to the response.__gettitem__/del that way there are no 2 right ways to do things? I would probably keep it around until 3.2... I personally like the whole respose.headers it's much more readable. -- You received this message because you are

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

Hi Florian, thank for your input, i dont belive in adding default names to environment variables, they're up to the user to define. Nothing will be given by default, you need the SECRET_KEY? `from_env` has no idea what that means, its just another name, so you tell it what it will do with this

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

Hi Carsten, great question! The idea as i see it is: having the least amount of moving parts the better. The trick here is unification, keep a single settings file with 99% of the configuration needed using environment variables/secrets/zookeeper/etc to swap out environment specific options

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

te is "look in the environment") will at least help > newer devs understand that this is a topic they should learn more about. > > Thanks, > > --Kit > > On Thu, Jun 25, 2020 at 11:16 AM Javier Buzzi > wrote: > >> Hi Bobby, yes, thank you, this looks a

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

/henriquebastos/python-decouple > > -bobby > > On Jun 25, 2020, at 4:47 AM, Javier Buzzi > wrote: > > Hey Tom, cool project haven't heard of it, looks to me more inline with > validating and converting user input from an api/form. I could really see > myself using this in m

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

to integrate it with django's settings so they're all exposed as > `settings.FOO`, and so on. > > I don't think I would want to integrate anything like this into Django > proper, but it might deserve a mention in the documentation. > > Tom > > On Wed, 24 Jun 2020 at 23:52

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

"you might want to get this >> from the env" helper would be a clear indication to a new dev that this is >> a matter to even consider. Adding other configuration-getting options like >> different secret-store file backends seems like a good next step. >>

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

I looked at the libs that do what we want: django-configurations - it looks like they use environment variables / either via loading them from the environ or a key/value pair file. Having classes inside the settings.py might be weird to people.. at the least very different. confucius - very

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

I think its great, but id add a little more customizability. I've added an example to your PR. -- 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

Re: Implement QuerySet.__contains__?

My 2 cents, I think @johan's suggestion makes sense. if obj in queryset: It's very pythonic. it should do what __len__ does and cache it, if you want the single quick db query you can always use exists(). ps @roger >>> timeit.timeit('m.GL.objects.filter(pk=x.pk)', setup='import myapp.models

Re: Disabling .delete() in querysets in Django

More to Tom's point, I'm currently working on an old app that the original intent was to never delete anything, ever. The original programmers did something similar to what you did with the exception that they added a "deleted_ts" field to every model, the model/queryset delete() would just

Re: Disabling .delete() in querysets in Django

> I can still delete objects from our admin interface, so it probably doesn't use the delete() queryset. I think you should look at https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1095-L1103 Individual objects are deleted individually, using the object.delete() --

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

> > On Tue, Apr 28, 2020, at 9:41 PM, charettes wrote: > > It's notoriously hard to distinguish between first-party and > > third-party apps but I know some package manage to do it relatively > > well (e.g. isort). > > > > Le mardi 28 avril 2020 14:32:13 UTC-4, J

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

020 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 squashing "django.contrib.auth" as an example, and > you're not going to have a fun time at that.. > > -- > You re

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

To do that we need to know which apps are part of your project, and which are not. Otherwise you'll be squashing "django.contrib.auth" as an example, and you're not going to have a fun time at that.. -- You received this message because you are subscribed to the Google Groups "Django

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

And then do? $ ./manage.py squashmigrations --crossapp=$(find . -name apps.py | sed 's|/apps.py$||; s|^./||; s|/|.|g' | xargs printf '%s,') We have 54 apps currently.. more to come. I'm sure there are projects out there with more, this can get frighting, specially for windows users -- not

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

Correct. Im adding that functionality currently -- im taking the VERY naive approach of looking at BASE_DIR and if the app is not in there, its foreign to the project. Some insight or better ideas to this would be appreciated. -- You received this message because you are subscribed to the

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

from the other project, and from there I will REALLY welcome your insight, guidance, and specially your criticism. Thank you! Javier Buzzi -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To u

[FEATURE] Allow squashmigrations to squash the whole project

for this? Thanks, Javier Buzzi -- 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.co

Re: GSoC 2020 Proposal for ModelStates in Migrations

imple class > instances) than creating classes hierarchy over and over again. > > > Le lundi 23 mars 2020 17:14:04 UTC-4, Javier Buzzi a écrit : >> >> I don't see how this solves anything. At the end of the day these "real" >> models, or at the very least,

Re: GSoC 2020 Proposal for ModelStates in Migrations

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? On Monday, March 23, 2020 at 12:59:55 PM

Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

. Thanks. On Saturday, January 4, 2020 at 12:00:11 PM UTC-5, Jon Dufresne wrote: > > An optional command line argument makes sense to me. +1 > > On Thu, Jan 2, 2020 at 2:11 PM Adam Johnson > > wrote: > >> I guess an optional kwarg would be okay then. >> >> On

Re: Extent of async integration into 3.0

What does this have to do with what Johan Schiff asked about "customizable urlize"? On Tuesday, January 7, 2020 at 1:55:00 PM UTC+1, Jure Erznožnik wrote: > > I've been monitoring this list for a bit, enough to see that 3.x is now > moving in the async direction. > > Is there a roadmap as to

Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

@adam I agree with your points, about data loss, but this can still see this as being beneficial, perhaps the approach was just too harsh. Perhaps adding a flag in the management command would get everyone on board? The flag being off by default and only turns on if you know what you’re doing

Re: United Nations: Expel Maduro from the Human Rights Council!

Aunque estoy de acuerdo contigo, esto no es el lugar correcto para pedir esto. Por favor bórralo. Esto no tiene nada que ver con django. Get Outlook for iOS From: django-developers@googlegroups.com on behalf of franklinit...@gmail.com

Re: Adding generated common table expressions

What do you think of this syntax instead? q1 = Book.objects.values('author_id').annotate(avg_price=Avg('price')) q2 = Author.objects.attach('book_prices', q1, id=F('book_prices__author_id' )) def attach(name, queryset, **params): # Would look something like this. ... Same sql output.