Re: Makemigrations hooks for third-party apps?

[Javier Buzzi]

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 2:42:34 AM UTC+2 charettes wrote:

> Hello Craig,
>
> There's unfortunately no way to hook into the migration auto-detector to 
> specify
> additional operations to be added.
>
> What I suggest you do instead is dynamically inject operations in the plan 
> that
> is about to be run by connecting a pre_migrate signal. When you detect
> CreateModel operations for subclasses of your AbtractModel you could insert
> operations to be performed before and after them. This is pattern we use
> internally to perform ContentType rename on RenameModel operations[0].
>
> As for the makemigrations hooks I think it would require a lot of thought 
> and
> efforts to get right. Right now the auto-detector is a black box that 
> deals with
> dependencies and model state deltas resolution.
>
> In an ideal world model/fields objects would be able to generate the list 
> of
> operations they require to move from state A to B as a public API and the
> auto-detector would simply iterate over the existing migrations state 
> models and
> compare them against the current state of the project.
>
> Best,
> Simon
>
> [0] 
> https://github.com/django/django/blob/525dc283a68c0d47f5eb2192cc4a20111d561ae0/django/contrib/contenttypes/management/__init__.py#L45-L84
>
>
> Le mardi 6 juin 2017 16:45:05 UTC-4, Craig de Stigter a écrit :
>>
>> Hi there
>>
>> I'm in the early stages of developing a third party app which makes heavy 
>> use of postgres extensions. The app provides an abstract model, so I won't 
>> have direct control of user's models or migrations. I'm having trouble 
>> getting it to generate sensible migrations for users.
>>
>> At present the migration process for users is going to be "copy and paste 
>> my migration file template into your project, and change the model names to 
>> match your app". As far as I can tell there is no way to generate 
>> migrations with anything custom.
>>
>> The operations I need to generate are:
>>
>>- CreateExtension()
>>- RunSQL() - (to create slightly non-standard constraints)
>>
>> e.g. perhaps my model could supply a couple of methods:
>>
>>- Model.Meta.pre_creation_operations() - returns a list of operations 
>>to apply before the auto-detected model operations, e.g. creating 
>>extensions etc
>>- Model.Meta.post_creation_operations() - the same but applied after 
>>the auto-detected operations, e.g. adding constraints/indexes.
>>
>> I'm envisaging that the operations returned from both methods would be 
>> deconstructed and copied into migration files when makemigrations is run.
>>
>> Has there been any discussion about this previously? I haven't found any.
>>
>> Thanks
>> Craig de Stigter
>>
>

-- 
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/1891cd07-6fa2-4e94-8105-bbae0f86a96dn%40googlegroups.com.

Re: Issue with multiple database backends

[Javier Buzzi]

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 seems like a genuine bug, Django should not assume that all
> > backends have the same max table name length. Please file a ticket.
> > 
>
> Right, but it may be a simpler bug than the one you have in mind.
>
> > >
> > > Issue i've found is that if i try and call the model
> > > 
> `ThisIsAReallyLongModelNameThatIsAlsoVeryOld.objects.using('old').count()`
> > > i get an error saying that the table
> > > `APP_THISISAREALLYLONGMODEL5300` does not exist, when it should be
> > > using `APP_THISISAREALLYLONGMODEL5BD6` instead.
>
> So, you get two different name truncations -- one if the model is
> instantiated with Oracle as the default connection (presumably that's
> the 5BD6 one), and another if it is instantiated with Postgres and
> later used via Oracle. I'd venture as far as guessing that the
> difference is that only in one of the cases, the name is turned to
> uppercase before shortening; this is how it was in a similar old case,
> solved years ago (there, the names of auto-generated through-tables for
> ManyToManyField were shortened in a different way than
> explicitly-created models, and hilarious breakage ensued when anyone
> wanted to add a field to a through table).
>
> I suspect the only fix needed is to make the two ways match
> (in favor of the "instantiated on Oracle" way). I doubt it would even
> require a deprecation.
>
> HTH,
> Shai.
>

-- 
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/4c70ad62-24e0-4e20-abe1-9815a35d2fben%40googlegroups.com.

Issue with multiple database backends

[Javier Buzzi]

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 try and call the model 
`ThisIsAReallyLongModelNameThatIsAlsoVeryOld.objects.using('old').count()` 
i get an error saying that the table `APP_THISISAREALLYLONGMODEL5300` does 
not exist, when it should be using `APP_THISISAREALLYLONGMODEL5BD6` 
instead. By the way when I use postgres, it works as expected: 
`ThisIsAReallyLongModelNameThatIsAlsoVeryOld.objects.using('default').count()`

This is because the default connection is used when the model is 
instantiated, and then its used from that moment on.

https://github.com/django/django/blob/stable/3.2.x/django/db/models/options.py#L207

This is an issue that seems to go back to the beginning of Django.

Is this something known? Is this something we can fix?

Thanks,


= here be dragons ===
as a temporary hack i did this for now, sorry for the formatting, google 
groups didn't let me format it the way i wanted.


from django.db.models.sql import compiler
from django.db.backends.utils import truncate_name


class ConnectionAwareAlias(dict):
def __init__(self, query, connection):
self.query = query
self.connection = connection
self['*'] = '*'

def __contains__(self, item):
model = self.query.model
db_table = "%s_%s" % (model._meta.app_label, model._meta.model_name)
if item == db_table:
if not self.get(item):
db_table = truncate_name(db_table, self.connection.ops.max_name_length())
self[item] = db_table

return True

return self.get(item) is not None


class NewSQLCompiler(compiler.SQLCompiler):
def __init__(self, query, connection, using):
super(NewSQLCompiler, self).__init__(query, connection, using)
self.quote_cache = ConnectionAwareAlias(query, connection)

compiler.SQLCompiler = NewSQLCompiler

-- 
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/95d2dd47-a635-4c6d-86ce-8dde8e37e536n%40googlegroups.com.

Re: queryset.values() / GROUP BY

[Javier Buzzi]

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 
> today.
> 
> Is there a deeper reason why this functionality is not available in Django 
> core, or is it just that nobody got around to implementing it yet? To me, it 
> seems like something that would be nice to have without having to rely on a 
> third-party package.
> 
> Any thoughts?
> 
> Regards,
> René
> 
> -- 
> 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/0cdf647e-295f-6948-abd0-696cb9859efe%40fleschenberg.net.

-- 
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/A1414E42-527A-4A08-AE64-1A2E88109CB3%40gmail.com.

Re: f-strings again.

[Javier Buzzi]

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 cases, but 
.format() is a lot more confortable to me... #personalbias.

- 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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/416274e2-c186-4964-941d-5d2512bb5071o%40googlegroups.com.

Re: HttpResponse headers interface

[Javier Buzzi]

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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e8e32943-841f-4cee-8654-a992f2c263f3o%40googlegroups.com.

Re: HttpResponse headers interface

[Javier Buzzi]

@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 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/86889efe-b876-46cc-8dc4-1559d6a6487do%40googlegroups.com.

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

[Javier Buzzi]

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 such 
as `from_env.str("SECRET_KEY")` or simply `from_env("SECRET_KEY")` if its a 
string. But if "SECRET_KEY" is taken by some other process and you need to 
add another one to be your SECRET_KEY for django and you call it "FOO" then 
`FOO` would be the name you pass to `from_env` and assign it to your 
SECRET_KEY = from_env('FOO'). Trying to really nail the point home: there 
are NO default environment names (other than DJANGO_SETTINGS_MODULE but 
that has nothing to do with this).

- 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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d6cf479b-4e37-411b-b999-73a5944995a3o%40googlegroups.com.

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

[Javier Buzzi]

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 
(activate debug mode? database connections, cache connections, 
domain_allowlist (formally whitelist), etc.)

This has happened a couple of times in my lifetime, stop me if you've heard 
it: You have N environments, they're all slightly different, you're working 
on local and some kind of qa environment, everything is going great, but 
you forgot to do that last minute change you did on the higher environments 
to the prod settings -- you deployed; deployment failed. Sound familiar? 
Having a single / or at least keeping the amount of environment setting 
files to a minimum will greatly benefit you in the long run, its also 
easier to test: remember flat is better than nested.

With the method i'm suggesting, your example would not need a 
localconfig.py since settings.py would just import them from the 
environment variables.

- 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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0047aea4-d07d-4559-b613-b3ab1976a9f9o%40googlegroups.com.

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

[Javier Buzzi]

Think of it like this, you make a simple settings/base.py where you define 
something like this:

from django.conf import from_env

MEDIA_PATH = '/mnt/media'  # hardcoded to show you don't have to use `
from_env`

DEBUG = from_env.bool('DEBUG')

SECRET_KEY = from_env('SECRET_KEY')

DATABASES = {
'default': from_env.db('POSTGRES_URL'),  # 
"postgres://user:pass@db.server:4321/db_name?params"
'extra': from_env.db('SQLITE_URL', 
default='sqlite:tmp/my-tmp-sqlite.db')
}

CACHES = {
'default': from_env.cache('MEMCACHE_URL'),
'redis': from_env.cache('REDIS_URL')
}

..

and you can still have an other settings/dev.py or settings/test.py that 
all inherit from settings/base.py and still can customize it some more in 
those files. I have a project that because of ops, environment variables 
are an issue and i have to rely on having multiple environment files, i 
dont like it, but i live with it, such is life. I much rather have a 
base.py that ALL environments use, and then have a tests.py that inherits 
from base.py and will add mocks to things like s3 and other things needed 
to ensure tests pass. But i would really recommend to keep the amount of 
environment files to an absolute minimum -- nevertheless this doesnt rob 
you of being able to accomplish what you're used to doing.

- Buzzi

On Thursday, June 25, 2020 at 4:12:26 PM UTC-4, Bobby Mozumder wrote:
>
> If you at least don’t separate all variables that are dependent on the 
> environment from the settings.py, then you’re going to have to edit your 
> settings.py file anyways, defeating the purpose of this. Database and Cache 
> connection settings are clearly dependent on the environment.
>
> -bobby
>
> On Jun 25, 2020, at 1:51 PM, Kit La Touche > 
> wrote:
>
> Wow, `distutils.util.strtobool` is great to know about!
>
> So, can we refocus this conversation? This is starting to look like 
> previous conversations on this topic, which pull in a lot of possibilities 
> but don't lead to a change. How do we go about generating a DEP or other 
> consensus-building tool on what we want here?
>
> It seems to me this conversation has historically gotten stuck by trying 
> to bite off a bigger bite. Therefore, I would recommend a minimal change 
> that gestures towards the direction we want to explore.
>
> Personally, I think that *at minimum* providing Django-builtin "get from 
> env"  helpers would be great; beyond that, I'd love to have them be 
> included around `DEBUG` and `SECRET_KEY` with the current values as 
> defaults, so they're optional. Once we see how this gets used, we can see 
> about passing it a file instead of `os.environ`, or borrowing other ideas 
> from any of the various supporting projects that have been suggested.
>
> It's clear that different people have different use-cases and different 
> needs, but regardless, I think that it's clear also that including values 
> like DEBUG and SECRET_KEY as *hard coded values in settings* by default 
> does not point people towards good practices. What "good practices" are is 
> likely to differ in each person's case, but I think that suggesting one 
> option (again, my vote 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 around the line of what i would like 
>> us to implement in Django. 
>>
>> Side note: i saw this config('DEBUG', default=False, cast=bool) and 
>> thought "there is NO WAY that works", that led me to from distutils.util 
>> import strtobool, absolute mind blown! Thanks!
>>
>> -Buzzi
>>
>> On Thursday, June 25, 2020 at 1:03:19 PM UTC-4, Bobby Mozumder wrote:
>>>
>>> There’s also python-decouple that I use that I haven’t seen mentioned in 
>>> this thread. It lets you set specific environment variables in a separate 
>>> .env file or INI file: https://github.com/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 my personal projects, however this looks like we'd be 
>>> going back to the class based configuration that im trying to avoid. 
>>> Nonetheless thank you for the share!
>>>
>>> - Buzzi
>>>
>>> On Thursday, June 25, 2020 at 4:34:11 AM UTC-4, Tom Carrick wrote:
>>>>
>>>> Javier, I just wanted to poi

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

[Javier Buzzi]

Hi Bobby, yes, thank you, this looks around the line of what i would like 
us to implement in Django. 

Side note: i saw this config('DEBUG', default=False, cast=bool) and thought 
"there is NO WAY that works", that led me to from distutils.util import 
strtobool, 
absolute mind blown! Thanks!

-Buzzi

On Thursday, June 25, 2020 at 1:03:19 PM UTC-4, Bobby Mozumder wrote:
>
> There’s also python-decouple that I use that I haven’t seen mentioned in 
> this thread. It lets you set specific environment variables in a separate 
> .env file or INI file: https://github.com/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 my personal projects, however this looks like we'd be 
> going back to the class based configuration that im trying to avoid. 
> Nonetheless thank you for the share!
>
> - Buzzi
>
> On Thursday, June 25, 2020 at 4:34:11 AM UTC-4, Tom Carrick wrote:
>>
>> Javier, I just wanted to point out another option for configuration: 
>> pydantic <https://pydantic-docs.helpmanual.io/> - it offers a very slick 
>> and intuitive interface for settings management across environments, 
>> seamless handing of environment variables by using type hints, and so on. I 
>> wouldn't recommend it for anything other than large sites with complex 
>> configurations, but it does work well for those, once you grapple with how 
>> 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, Javier Buzzi  wrote:
>>
>>> This makes sense, I have a project that has a lot of settings files that 
>>> get activated depending on the value of DJANGO_SETTINGS_MODULE. The 
>>> solution i outlined above takes your reservations under consideration, if 
>>> you want to use it, great, if not also great -- its a supplement not a 
>>> requirement.
>>>
>>> - Buzzi
>>>
>>> On Wednesday, June 24, 2020 at 5:24:35 PM UTC-4, Dan Davis wrote:
>>>>
>>>>  tMost of the world is not as seamless as heroku.  My DevOps won't give 
>>>> me any more than a handful of environment variables.  I wanted something 
>>>> like DATABASE_URL, but all I have is DJANGO_LOG_DIR and 
>>>> DJANGO_SETTINGS_MODULE, and so I need many, many settings files. I think 
>>>> that happens a lot, and maybe a common pattern.
>>>>
>>>> From a 12factor perspective, I would like to get it down to local 
>>>> settings (development) and production settings - yet for a lot of users, 
>>>> DevOps is not really supporting a full PaaS-like experience any way.
>>>>
>>>> So - all of this has to be optional, which seems to rule out making it 
>>>> part of the starting project template.  For sure, I've got my personal 
>>>> template, and work has an on-premise template and a Cloud template as well 
>>>> - but the department of developers doesn't always use these.  I find 
>>>> databases containing the tables for other projects, long after the models 
>>>> and migrations are gone, indicating a start by copy mode.
>>>>
>>>> On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche  wrote:
>>>>
>>>>> Carlton—thanks very much for the feedback. Javier—likewise. In 
>>>>> particular, the imagined API you describe above is very appealing to me: 
>>>>> start with `from_env` and then if you learn more about this and want to, 
>>>>> add in some `EnvFileLoader`.
>>>>>
>>>>> I want to make clear my motivation and agenda here: I have recently 
>>>>> had some conversations with newer devs about their experiences with 
>>>>> deployment of apps they're working on, and with a friend at Heroku about 
>>>>> his informal research into the problems people have with the same. One 
>>>>> recurring friction point (and this is not just on Heroku at all, to be 
>>>>> clear) is that there are a number of things that people *don't know 
>>>>> they need to configure* for a working deployment.
>>>>>
>>>>> There are four settings that are recurring particular gotchas that 
>>>>> people m

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

[Javier Buzzi]

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 my personal projects, however this looks like we'd be 
going back to the class based configuration that im trying to avoid. 
Nonetheless thank you for the share!

- Buzzi

On Thursday, June 25, 2020 at 4:34:11 AM UTC-4, Tom Carrick wrote:
>
> Javier, I just wanted to point out another option for configuration: 
> pydantic <https://pydantic-docs.helpmanual.io/> - it offers a very slick 
> and intuitive interface for settings management across environments, 
> seamless handing of environment variables by using type hints, and so on. I 
> wouldn't recommend it for anything other than large sites with complex 
> configurations, but it does work well for those, once you grapple with how 
> 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, Javier Buzzi  > wrote:
>
>> This makes sense, I have a project that has a lot of settings files that 
>> get activated depending on the value of DJANGO_SETTINGS_MODULE. The 
>> solution i outlined above takes your reservations under consideration, if 
>> you want to use it, great, if not also great -- its a supplement not a 
>> requirement.
>>
>> - Buzzi
>>
>> On Wednesday, June 24, 2020 at 5:24:35 PM UTC-4, Dan Davis wrote:
>>>
>>>  tMost of the world is not as seamless as heroku.  My DevOps won't give 
>>> me any more than a handful of environment variables.  I wanted something 
>>> like DATABASE_URL, but all I have is DJANGO_LOG_DIR and 
>>> DJANGO_SETTINGS_MODULE, and so I need many, many settings files. I think 
>>> that happens a lot, and maybe a common pattern.
>>>
>>> From a 12factor perspective, I would like to get it down to local 
>>> settings (development) and production settings - yet for a lot of users, 
>>> DevOps is not really supporting a full PaaS-like experience any way.
>>>
>>> So - all of this has to be optional, which seems to rule out making it 
>>> part of the starting project template.  For sure, I've got my personal 
>>> template, and work has an on-premise template and a Cloud template as well 
>>> - but the department of developers doesn't always use these.  I find 
>>> databases containing the tables for other projects, long after the models 
>>> and migrations are gone, indicating a start by copy mode.
>>>
>>> On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche  wrote:
>>>
>>>> Carlton—thanks very much for the feedback. Javier—likewise. In 
>>>> particular, the imagined API you describe above is very appealing to me: 
>>>> start with `from_env` and then if you learn more about this and want to, 
>>>> add in some `EnvFileLoader`.
>>>>
>>>> I want to make clear my motivation and agenda here: I have recently had 
>>>> some conversations with newer devs about their experiences with deployment 
>>>> of apps they're working on, and with a friend at Heroku about his informal 
>>>> research into the problems people have with the same. One recurring 
>>>> friction point (and this is not just on Heroku at all, to be clear) is 
>>>> that 
>>>> there are a number of things that people *don't know they need to 
>>>> configure* for a working deployment.
>>>>
>>>> There are four settings that are recurring particular gotchas that 
>>>> people miss: the secret key, debug, static files, and databases. Static 
>>>> files seems big and out of scope, databases seems adequately handled by 
>>>> dj-database-url for most cases, and if your case is more complex, you'll 
>>>> learn it, but the other two (secret key and debug) seemed easy enough to 
>>>> flag as "you probably need to configure these!" with this sort of change 
>>>> to 
>>>> settings. This would be a first step towards shortening the distance from 
>>>> `startproject` to a working deployment.
>>>>
>>>> Newer devs in particular have, based on my conversations and this 
>>>> friend's research, been unlikely to (a) know that there are different 
>>>> `startproject` templates, and (b) feel equipped to choose one, if they do 
>>>> know.
>>>>
>>>> My hope is to make the s

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

[Javier Buzzi]

This makes sense, I have a project that has a lot of settings files that 
get activated depending on the value of DJANGO_SETTINGS_MODULE. The 
solution i outlined above takes your reservations under consideration, if 
you want to use it, great, if not also great -- its a supplement not a 
requirement.

- Buzzi

On Wednesday, June 24, 2020 at 5:24:35 PM UTC-4, Dan Davis wrote:
>
>  tMost of the world is not as seamless as heroku.  My DevOps won't give me 
> any more than a handful of environment variables.  I wanted something like 
> DATABASE_URL, but all I have is DJANGO_LOG_DIR and DJANGO_SETTINGS_MODULE, 
> and so I need many, many settings files. I think that happens a lot, and 
> maybe a common pattern.
>
> From a 12factor perspective, I would like to get it down to local settings 
> (development) and production settings - yet for a lot of users, DevOps is 
> not really supporting a full PaaS-like experience any way.
>
> So - all of this has to be optional, which seems to rule out making it 
> part of the starting project template.  For sure, I've got my personal 
> template, and work has an on-premise template and a Cloud template as well 
> - but the department of developers doesn't always use these.  I find 
> databases containing the tables for other projects, long after the models 
> and migrations are gone, indicating a start by copy mode.
>
> On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche  > wrote:
>
>> Carlton—thanks very much for the feedback. Javier—likewise. In 
>> particular, the imagined API you describe above is very appealing to me: 
>> start with `from_env` and then if you learn more about this and want to, 
>> add in some `EnvFileLoader`.
>>
>> I want to make clear my motivation and agenda here: I have recently had 
>> some conversations with newer devs about their experiences with deployment 
>> of apps they're working on, and with a friend at Heroku about his informal 
>> research into the problems people have with the same. One recurring 
>> friction point (and this is not just on Heroku at all, to be clear) is that 
>> there are a number of things that people *don't know they need to 
>> configure* for a working deployment.
>>
>> There are four settings that are recurring particular gotchas that people 
>> miss: the secret key, debug, static files, and databases. Static files 
>> seems big and out of scope, databases seems adequately handled by 
>> dj-database-url for most cases, and if your case is more complex, you'll 
>> learn it, but the other two (secret key and debug) seemed easy enough to 
>> flag as "you probably need to configure these!" with this sort of change to 
>> settings. This would be a first step towards shortening the distance from 
>> `startproject` to a working deployment.
>>
>> Newer devs in particular have, based on my conversations and this 
>> friend's research, been unlikely to (a) know that there are different 
>> `startproject` templates, and (b) feel equipped to choose one, if they do 
>> know.
>>
>> My hope is to make the smallest possible change to just start us moving 
>> towards more clearly flagging, especially for newer devs, "these are things 
>> that will need additional configuration in order to move from 'works on my 
>> machine' to 'deployed'."
>>
>> Towards that end, I thought that adding a "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.
>>
>> Thanks,
>>
>> --Kit
>>
>> On Wed, Jun 24, 2020 at 11:13 AM Javier Buzzi > > wrote:
>>
>>> 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 simplistic, only supports environ and is classed based, 
>>> similar to django-configurations.
>>> django-environ - supports env file and environ, non-class based.
>>> dynaconf - supports all kinds of loading options (toml, json, ini, 
>>> environ, .env +) non-class based.
>>>
>>> In my opinion, django-environ and dynaconf would be the easiest to sell 
>>> to the community, it would require the least changes/paradigm shifts from 
>>> how everyone is already using django.
>>>
>>> Personally, i wou

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

[Javier Buzzi]

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 simplistic, only supports environ and is classed based, 
similar to django-configurations.
django-environ - supports env file and environ, non-class based.
dynaconf - supports all kinds of loading options (toml, json, ini, environ, 
.env +) non-class based.

In my opinion, django-environ and dynaconf would be the easiest to sell to 
the community, it would require the least changes/paradigm shifts from how 
everyone is already using django.

Personally, i would really like to see something like this inside my 
settings.py:

from django.conf import from_env  # using standard os.environ

DEBUG = from_env.bool("DEBUG", default=False)

DATABASES = {
"default":  from_env.db("DATABASE_URL")  # crash if it cant find it
}

...

for more complex examples:

from django.conf import EnvFileLoader

from_env = EnvFileLoader("path/to/.secret")

...

We can have how ever many loaders we want: toml, json, ini .. 

This is both borrowing heavily from dynaconf and django-environ, making the 
fewest changes to how people are accustomed to doing things.

.. what do you guys think?

- 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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/41cea044-ffe1-445d-ab7a-a65f69e6d85ao%40googlegroups.com.

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

[Javier Buzzi]

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 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/8dc94197-fa0c-442a-8f97-3d7990a3a2c2o%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Javier Buzzi]

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 as m;x = m.GL.objects.all()[324]', number=100)
0.05818330496549606

is not doing anything, add a `.exists()` or `len(..)` or something to evaluate 
the queryset. That number is WAY too low.

-- 
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/5195eb58-8600-43a3-ad46-1c72f691f04b%40googlegroups.com.

Re: Disabling .delete() in querysets in Django

[Javier Buzzi]

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 
add now() to the aforementioned field. This all seemed great on the 
surface, until we realized the app needed tests, they wrote none. Sometimes 
even in the more severe of cases, you want to do delete(), inside tests or 
otherwise. As an ongoing effort, we have created a soft_delete() and left 
delete() alone, created a Admin mixin called SoftDeleteMixin that adds an 
extra button in the details and a new action to the list view.

What you're suggesting definitely something that should be there, i really 
suggest you reconsider your approach.

-- 
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/4f4b6233-dde9-4b20-81ba-10ff377a76a9%40googlegroups.com.

Re: Disabling .delete() in querysets in Django

[Javier Buzzi]

> 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()

-- 
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/f997487a-3b8b-4ae6-b099-e4a7af08e510%40googlegroups.com.

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

[Javier Buzzi]

How terrible would something like this be:

class AppConfig:
"""Class representing a Django application and its configuration."""

.

   @cached_property
def is_squashable(self):
if hasattr(self, 'squashable'):
return self.squashable
 code from isort

in your local apps.py you can chose to do:

class MyAppConfig(AppConfig):
squashable = False  # or omit it, if you want django to figure it out

This plays back into a requirement i had, where we have apps just for testing 
inside our application that we don't want squashed. We would also need to have 
a little more binding power from Migration to the AppConfig, since we would 
need to pick this value up. From my naive research, doesn't seem like an issue 
since Apps should always exist in order to make the migration anyway, i dont 
see a big risk in coupling the two.

What does everyone think?

Buzzi


> On Apr 28, 2020, at 8:33 PM, charettes  wrote:
> 
> You don't have to explicitly configure them as long as you run isort within a 
> Python environment that has all dependency installed properly. If you want to 
> run isort without installing all of the deps of your package you have to 
> explicitly specify which module is first or third party.
> 
> Here's the routine I was referring to 
> https://github.com/timothycrosley/isort/blob/0ee43b6a4f3c40876c3c7714846ecf8e584dc314/isort/finders.py#L165-L191
>  
> <https://github.com/timothycrosley/isort/blob/0ee43b6a4f3c40876c3c7714846ecf8e584dc314/isort/finders.py#L165-L191>
> 
> Simon
> 
> Le mardi 28 avril 2020 16:04:14 UTC-4, Markus Holtermann a écrit :
> But for isort one specifies the `known_first_party` and `known_third_party` 
> packages. https://github.com/timothycrosley/isort#configuring-isort 
> <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: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, Javier Buzzi a écrit : 
> > > To be kind to the user, absolutely! .. any idea on how to implement it 
> > > 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 : 
> > >>> 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 developers (Contributions to Django itself)" group. 
> > >>  To unsubscribe from this group and stop receiving emails from it, send 
> > >> an email to django-d...@googlegroups.com <>. 
> > >>  To view this discussion on the web visit 
> > >> https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com
> > >>  
> > >> <https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com><https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com?utm_medium=email_source=footer
> > >>  
> > >> <https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com?utm_medium=email_source=footer>>.
> > >>  
> > > 
> > 
> >  -- 
> >  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-d...@ <>googlegroups.com <http://googlegroups.com/>. 
> >  To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/8af08a8f-4f4d-4fef-8daa-e3743a1f8468%40googlegroups.com
> >  
> > <https://groups.google.com/d/msgid/django-developers/8af08a8f-4f4d-4fef-8daa-e3743a1f8468%40googlegroups.com>
> >  
> > &

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

[Javier Buzzi]

To be kind to the user, absolutely! .. any idea on how to implement it 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 :
> 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 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com?utm_medium=email_source=footer>.

-- 
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/DB50F1F6-6811-49C2-8937-584E8115932C%40gmail.com.

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

[Javier Buzzi]

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 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/3cd4db15-c4b0-416f-8c51-2f67610a37c8%40googlegroups.com.

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

[Javier Buzzi]

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 
sure what the equivalent powershell/batch command is -- do they have 
limitations in terms of command length? Perhaps I'm only looking at this 
from my narrow point of view where we squash constantly, every app after 
each release, maybe this is not for everyone. If you guys think this is the 
way to go, let's do that then.

-- 
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/301d4b7c-1023-41fc-b2f2-89676ee8febe%40googlegroups.com.

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

[Javier Buzzi]

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 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/f202a4bb-1d7b-4c85-9695-f4ef3b996c3c%40googlegroups.com.

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

[Javier Buzzi]

Sounds great Andrew, i'm going to say this up front:

1. You're awesome, thank you for making south and migrations.
2. I'm inevitably need your help on this one, there were a lot of hacks I 
did because I couldn't come up with a better way. I'll get started, as a v1 
to just port all the work done 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 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/220584c4-a0bc-4535-906e-f120b7080add%40googlegroups.com.

[FEATURE] Allow squashmigrations to squash the whole project

[Javier Buzzi]

This comes from a place of headaches: we're a large team, and our sprint 
are a month long, in that month we generate a lot of migrations, after a 
couple of sprints we see our tests take a real toll when running 
migrations, this is due to constantly adding columns/deleting columns, 
moving data around -- what normally happens with an ever changing app.

The way quashing migrations currently works is by an app by app, I'm 
proposing that if no arguments are supplied (no app_label, 
start_migration_name, migration_name) to squash the entire project, who's 
apps belong to the project of course.

I'm hopping that I can get all the modifications already done to this 
project: https://github.com/kingbuzzman/django-squash and simply integrate 
it directly into the django source. I don't want to take such an 
undertaking and just have the PR be rejected.

Is there any interest 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.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ad3e7507-01af-49a6-ab15-e1b6d7d32bb7%40googlegroups.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Javier Buzzi]

Understood. Thanks.

On Monday, March 23, 2020 at 5:48:43 PM UTC-4, charettes wrote:
>
> 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 the project in the first place.
>
> To me the abstract section clearly highlights why this is useful. Right 
> now the schema editor requires access to *rendered* model classes which is 
> quite slow as it involves dynamically creating (or recreating) Python 
> classes and all its dependency chain on most alterations during migration 
> application.
>
> It's way cheaper to create and alter ModelState instances (simple 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, 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 UTC-4, Sanskar Jaiswal wrote:
>>>
>>> Hey everyone,
>>>
>>> Here is my proposal for GSoC. My project is based upon making use of 
>>> ModelState during the migrated phase of the project, rather than rendering 
>>> fake Models.
>>>
>>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>>
>>> Feedback and criticism is highly appreciated.
>>>
>>> Thanks!
>>> Kind regards
>>> Sanskar
>>>
>>

-- 
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/bab34155-12b8-41fb-b58f-009042089e9c%40googlegroups.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Javier Buzzi]

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 UTC-4, Sanskar Jaiswal wrote:
>
> Hey everyone,
>
> Here is my proposal for GSoC. My project is based upon making use of 
> ModelState during the migrated phase of the project, rather than rendering 
> fake Models.
>
> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>
> Feedback and criticism is highly appreciated.
>
> Thanks!
> Kind regards
> Sanskar
>

-- 
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/3509e4d0-e99c-4ff3-a4d0-45a5c3a988e3%40googlegroups.com.

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

[Javier Buzzi]

Hey guys, looks like gowtham added  a new PR, can you guys add some insight?

https://github.com/django/django/pull/12558
https://code.djangoproject.com/ticket/31123

The question of what to call the flag that will add this functionality has 
come up, I'm hoping one of you has a better name.

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 Thu, 2 Jan 2020 at 03:08, Javier Buzzi > > wrote:
>>
>>> @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 
>>> and enable it. At any rate i believe from what i can i see in the code it 
>>> will still prompt you to delete the items it finds unless you added the 
>>> ——no—input which prevents helps with data loss.
>>>
>>> -- 
>>> 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-d...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/5c55fdaa-8d89-4baa-a08d-68b0e84c610c%40googlegroups.com
>>> .
>>>
>>
>>
>> -- 
>> Adam
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM3Hu_ZKWUj46%3D0BYN8XECG0OT_kMLNUgaopKXhJOEfJ5Q%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/CAMyDDM3Hu_ZKWUj46%3D0BYN8XECG0OT_kMLNUgaopKXhJOEfJ5Q%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/7312db0c-cd6b-49a6-9123-82c545304692%40googlegroups.com.

Re: Extent of async integration into 3.0

[Javier Buzzi]

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 where we want to get with this direction? 
>
>
> Or, to ask more directly: 
>
> I have been looking into django-channels for a while in order to start 
> catering for ever-increasing demands for more and more responsiveness in 
> my apps. Basically I see django-channels as a good approach at getting 
> the server to actually PUSH information to the clients. I sure hope I'm 
> not just wishful here, but that's how I understood this particular facet 
> of the project. There are some other things I also see quite appealing 
> in there. 
>
> Anyway, I understood that django-channels was a project just a tad too 
> big to simply be integrated into Django, but was heavily supported by 
> django core team? 
>
> OTOH I fear that with core django moving towards async will make 
> django-channels either hard to maintain or outright obsolete. 
>
> So, to finally arrive at the question: is the async action I have been 
> seeing going anywhere near where django-channels is today or is it a 
> completely separate effort? If the latter, what's the future outlook for 
> django-channels? 
>
>
> I sure hope I'm asking this in the right mailing list. 
>
>
> Thanks, 
> Jure 
>
>

-- 
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/17d5062b-b7cb-419f-9d72-560eb1e7ef34%40googlegroups.com.

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

[Javier Buzzi]

@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 and enable it. At 
any rate i believe from what i can i see in the code it will still prompt you 
to delete the items it finds unless you added the ——no—input which prevents 
helps with data loss.

-- 
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/5c55fdaa-8d89-4baa-a08d-68b0e84c610c%40googlegroups.com.

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

[Javier Buzzi]

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
Sent: Monday, December 23, 2019 09:48
Subject: United Nations: Expel Maduro from the Human Rights Council!

Hola,

Acabo de firmar la petición de "United Nations: Expel Maduro from the Human 
Rights Council!" y me encantaría que me ayudaras sumando tu firma.

Nuestro objetivo es llegar a 150,000 firmas y necesitamos más apoyo. Para 
obtener más información y firmar la petición puedes abrir el siguiente link:

http://chng.it/GpgXc5d9WW

¡Gracias!
Franklin

--
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/CAMsjBK%2Bg-8khceMy2nwxozKK5BFQLxqW3sjLeE_sViAmvw8ARg%40mail.gmail.com.

-- 
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/VI1P195MB068768CF2F98F199A904FD7CFF290%40VI1P195MB0687.EURP195.PROD.OUTLOOK.COM.

Re: Adding generated common table expressions

[Javier Buzzi]

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.

On Thursday, April 6, 2017 at 9:14:01 AM UTC-4, Anssi Kääriäinen wrote:
>
> On Thursday, April 6, 2017 at 11:53:32 AM UTC+3, Marc Tamlyn wrote:
>>
>> Regarding Anssi's comments about SubQuery, we do now have that in core as 
>> of 1.11 [0]. It does look like an .attach() approach might actually have 
>> been a nicer version of this, but on the other hand it's currently 
>> implementable solely with the Expressions API. It seems like the OuterRef 
>> is very similar to your queryset.ref(). An even nicer approach using attach 
>> could be to say qs.attach(q1=some_qs).filter(a=F('q1__b'))?
>>
>
> Hmmh, we have one form of SubQuery, but that's actually for SELECT clause, 
> not for FROM clause. I believe the same class won't work for the CTE or 
> subquery in FROM clause case.
>
> As for the attach(), seems like a really nice syntax. We do need something 
> for generating the join clause for the JOIN. If you look at an example:
> q1 = Book.objects.values('author_id').annotate(avg_price=Avg('price'))
> q2 = Author.objects.attach(q1=q1)
> it needs to create something like:
> WITH q1 AS (
> SELECT author_id, avg(price) FROM book GROUP BY author_id
> )
> SELECT author.id, author.name
>FROM author
>LEFT JOIN q1 ON author.id = q1.author_id;
>
> Or, equivalently without the CTE:
>
> SELECT author.id, author.name
>FROM author
>LEFT JOIN ( SELECT author_id, avg(price) FROM book GROUP BY author_id) 
> ON author.id = q1.author_id;
>
> Now, the main points are:
>1. There is no need to design this to be about CTEs. That just limits 
> the feature from backends that don't have CTEs without any real benefit. 
> From Django's perspective the two above queries are the same.
>2. We do need something for the JOIN ON condition. In some cases Django 
> could guess this, but there needs to be an explicit way to express the join 
> condition.
>
> If we allow usage of expressions from the attached queryset, but don't try 
> to go for cases where model instance are created from the attached 
> queryset, this will be both possible to implement without having to write a 
> change-everything patch, and this will also be a really nice feature.
>
> For recursive CTEs, I'd leave that strictly as a later step. The only 
> thing we need to check right now is that we don't do something that 
> prevents a good recursive CTEs implementation later on.
>
>  - Anssi
>
>>
>> Looking forwards to seeing a DEP!
>>
>> [0] 
>> https://docs.djangoproject.com/en/1.11/ref/models/expressions/#subquery-expressions
>>
>> On 22 March 2017 at 01:32, Ashley Waite  wrote:
>>
>>> Here's the code changes I've made, noting that some of them were to 
>>> shove in a generalised VALUES clause that mocks being a queryset, so that 
>>> it plays with the same interface.
>>>
>>>
>>> https://github.com/django/django/compare/master...ashleywaite:cte-dev#files_bucket
>>>
>>> I've had a glance at cte-trees/cte-forest and once general CTEs are 
>>> worked out expanding that to include recursive CTEs wouldn't be too 
>>> difficult, and that would greatly simplify the implementation of cte-forest 
>>> to the extent that it might be viable as a django data/reference type.
>>>
>>> - Ashley
>>>
>>>
>>> On Saturday, March 18, 2017 at 8:28:53 PM UTC+11, Josh Smeaton wrote:

 Thanks for bringing this up Ashley, and for all of the detail you 
 provided. I'd certainly like to see CTEs make their way into Django, 
 provided we could come up with a nice enough API. From the look of it, 
 you've already got something that works with an okay API so I'm hopeful.

 I'd be very interested in seeing your POC too if you're able to share.

 From looking very briefly at django-cte-trees it doesn't aim to support 
 user defined CTEs for anything other than recursive queries. I'd be 
 interested in seeing, as part of a DEP, how CTE inclusion in django core 
 could support the cte-trees project from an API perspective.

 On Friday, 17 March 2017 22:28:17 UTC+11, Ashley Waite wrote:
>
> Hey all,
>
>
> I'd like to suggest adding Common Table Expression (CTE) query 
> generation as a feature to Django.
>
> I've been working on a project that required manipulation of many 
> records at once, and as with many ORMs found that this wasn't an ideal 
> use-case in Django. As the rest of our code base and related projects are 
> in Django, there was a strong preference to find a way to do it and keep 
> to 
> the same model-is-the-truth design.
>
> I first did this by writing some hackish functions using raw querysets 
> and generating my own CTE based queries, but