Re: Welcome email

[Jure Erznožnik]

I think this thread was abandoned, but wrongfully so. Frequency of 
unrelated posts is increasing lately.

Are there any serious issues with the moderation queue Google provides?

Reminder: https://support.google.com/groups/answer/2466386?hl=en


LP,
Jure

On Saturday, 25 July 2020 at 00:58:26 UTC+2 m...@kye.id.au wrote:

> This issue is exacerbated by similarly unaware / uncaring mailing list 
> users responding to support requests.
>
> What is the best path forward here?
>
> On 10 Jul 2020, at 3:09 pm, Jure Erznožnik  wrote:
>
>  
>
> I too volunteer for the screening job. 
>
> LP,
> Jure
> On 09/07/2020 16:10, Peter Inglesby wrote:
>
> Hi folks,
>
> Is there any moderation for posts from new users?  It can be enabled 
> , and I'd be 
> willing to be part of a team that filters posts from new users.
>
> All the best,
>
> Peter.
>
> On Thu, 9 Jul 2020 at 13:59, Adam Johnson  wrote:
>
>> I think that's a good improvement, not bikeshedding :)
>>
>> On Thu, 9 Jul 2020 at 13:17, Shai Berger  wrote:
>>
>>> Sorry for the bike-shedding, but I think the text should drop the
>>> "using Django" language. The people who come here with these questions
>>> clearly think of themselves as developers, not users.
>>>
>>> IMO It should go something like,
>>>
>>> Welcome to django-developers, the mailing list for discussion
>>> of the development of Django itself.
>>>
>>> This mailing list is not for support developing apps and
>>> websites with Django. For support, please follow the "Getting
>>> Help" page: https://docs.djangoproject.com/en/3.0/faq/help/ .
>>> This page will direct you to the django-users mailing list or
>>> other resources, so you can find people who are willing to
>>> support you, and to ask your question in a way that makes it
>>> easy for them to answer.
>>>
>>> Thanks,
>>>
>>> The Django Community
>>>
>>>
>>>
>>> On Wed, 8 Jul 2020 11:50:16 +0100
>>> Adam Johnson  wrote:
>>>
>>> > Okay I'm in favour. That said, there's already a banner on the groups
>>> > page:
>>> > 
>>> > This group is for the discussion of the development of Django itself.
>>> > If
>>> > > you want to ask questions about using Django, please post on
>>> > > django-users.
>>> > >
>>> > 
>>> > Suggested wording, adapted from my templated reply:
>>> > 
>>> > Welcome to django-developers, the mailing list for discussion of the
>>> > > development of Django itself.
>>> > >
>>> > > This mailing list is not for support using Django. For support,
>>> > > please follow the "Getting Help" page:
>>> > > https://docs.djangoproject.com/en/3.0/faq/help/ . This page will
>>> > > direct you to the django-users mailing list or other resources, so
>>> > > you can find people who are willing to support you, and to ask your
>>> > > question in a way that makes it easy for them to answer.
>>> > >
>>> > > Thanks,
>>> > >
>>> > > The Django Community
>>> > >
>>> > 
>>> > Who has access to add this? Someone from the DSF board, the ops team,
>>> > or the fellows?
>>> > 
>>> > On Mon, 6 Jul 2020 at 00:02, Ahmad A. Hussein
>>> >  wrote:
>>> > 
>>> > > +1 on this. Here's the relevant feature
>>> > >  I found.
>>> > >
>>> > >
>>> > > Ahmad
>>> > >
>>> > > On Sun, Jul 5, 2020 at 7:58 PM Adam Johnson  wrote:
>>> > >
>>> > >> I can't find a google groups feature that would allow this. Do you
>>> > >> know of one? It might otherwise require a custom bot.
>>> > >>
>>> > >> On Sun, 5 Jul 2020 at 16:14, Arvind Nedumaran
>>> > >>  wrote:
>>> > >>
>>> > >>> Oh I understand. I meant we could include the distinction in the
>>> > >>> welcome email and possibly a link to the other list.
>>> > >>>
>>> > >>> That may reduce the number of people who may be looking for help
>>> > >>> but end up here mistakenly?
>>> > >>>
>>> > >>> Get Outlook for Android 
>>> > >>>
>>> > >>> --
>>> > >>> *From:* django-d...@googlegroups.com <
>>> > >>> django-d...@googlegroups.com> on behalf of אורי
>>> > >>>  *Sent:* Sunday, July 5, 2020 8:39:22 PM
>>> > >>> *To:* Django developers (Contributions to Django itself) <
>>> > >>> django-d...@googlegroups.com>
>>> > >>> *Subject:* Re: Welcome email
>>> > >>>
>>> > >>> I think because this list is called Django developers and what we
>>> > >>> call "Django users" are also developers who use Django. But they
>>> > >>> are developers.
>>> > >>>
>>> > >>> אורי
>>> > >>> u...@speedy.net
>>> > >>>
>>> > >>>
>>> > >>> On Sun, Jul 5, 2020 at 5:59 PM Arvind Nedumaran
>>> > >>>  wrote:
>>> > >>>
>>> > >>> Hey everyone,
>>> > >>>
>>> > >>> I notice that people who try to find support on using Django
>>> > >>> mistakenly post in this list and sometime usually has to write an
>>> > >>> explanation about how this is the wrong place.
>>> > >>>
>>> > >>> Could we possibly as a welcome email whenever someone joins the
>>> > >>> 

Re: Instance Based Management?

[Jure Erznožnik]

Hi Matthew,

I think you found the wrong mailing list for this question. Might I 
suggest you try django-us...@googlegroups.com? The question seems better 
suited there.


That said, I don't know why you wouldn't want to use foreign keys in 
this scenario, but Django does support a thing called content types 
 for 
what you seem to be suggesting. There's a section on that page called 
"Generic relations 
". 



Have a look.

LP,
Jure

On 27. 10. 20 01:21, Matthew Amstutz wrote:


Hello, I was wondering about instance based management. If I'm wrong, 
please tell me.


When we have users and user generated content in a large database, 
query times are increased significantly. Why is there no instance 
based manager (like the models.Manager()) that basically generates a 
table for each user and queries ONLY that table? Would that not just 
flatten the database instead of increasing it's size? For example, if 
we have 1,000,000 users all of which generate at least 10 posts per 
day and one of the users only generates 5 in the span of 10 days, 
unless we have a many to many field or something to hold those five 
posts, the query time to find their posts would be ridiculous.


So if we have a table generated for each user that holds arbitrary 
connections to anything they generate, it would in theory cut query 
times significantly. Why is there no feature like this? Again, if I'm 
wrong please tell me but the amount of tables doesn't matter and 
instead the data they hold does so, in my understanding, 1,000,000,000 
posts will always be the size of 1,000,000,000 posts no matter their 
organization.


I've got ideas on implementation and even asyncronous supports as well 
as customization but I have no idea how to bring this up to the django 
developers and I'm not even sure it would work (though, no matter how 
hard I try, I can't see anything wrong with it).


Let me know your input and if there's a way I can ask the django devs 
about this and possibly even suggest a few things pertaining to it. 
I'd like to help make django the best it can be and if this works and 
we can implement it, django will be very fast with user generated content.

--
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/7e36ded7-2f3d-43c2-881c-cbc75c80b5c2n%40googlegroups.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/944bfa26-a0bf-69bb-f76a-c0654910eb20%40gmail.com.

Re: Instance Based Management?

[Daryl]

What you are describing sounds like denormalisation, but the first step
would be to ensure that the indexes on the child tables are being created.

The query time to find rows if the lookup field is indexed is close to
linear, without an index it will be close to exponential.
You should only denormalise after you have investigated the root cause of
your performance issues. Most times, denormalization is a form of premature
optimization [ https://stackify.com/premature-optimization-evil/ ]
If you are talking about virtual denormalisation (ie a view or table
generated by the manager you mention) then this relies again on indexing of
the underlying data to work, so you get no performance gain.
Correct me if I'm wrong, but AFAIK this is true of most managers - they
help you with your logical view of the data, not the performance of
retrieving it.

There are many django deployments where the performance is fine with orders
of magnitude more data than you are referring to, it just takes careful
planning.

D


On Tue, 27 Oct 2020 at 13:40, Matthew Amstutz 
wrote:

>
> Hello, I was wondering about instance based management. If I'm wrong,
> please tell me.
>
> When we have users and user generated content in a large database, query
> times are increased significantly. Why is there no instance based manager
> (like the models.Manager()) that basically generates a table for each user
> and queries ONLY that table? Would that not just flatten the database
> instead of increasing it's size? For example, if we have 1,000,000 users
> all of which generate at least 10 posts per day and one of the users only
> generates 5 in the span of 10 days, unless we have a many to many field or
> something to hold those five posts, the query time to find their posts
> would be ridiculous.
>
> So if we have a table generated for each user that holds arbitrary
> connections to anything they generate, it would in theory cut query times
> significantly. Why is there no feature like this? Again, if I'm wrong
> please tell me but the amount of tables doesn't matter and instead the data
> they hold does so, in my understanding, 1,000,000,000 posts will always be
> the size of 1,000,000,000 posts no matter their organization.
>
> I've got ideas on implementation and even asyncronous supports as well as
> customization but I have no idea how to bring this up to the django
> developers and I'm not even sure it would work (though, no matter how hard
> I try, I can't see anything wrong with it).
>
> Let me know your input and if there's a way I can ask the django devs
> about this and possibly even suggest a few things pertaining to it. I'd
> like to help make django the best it can be and if this works and we can
> implement it, django will be very fast with user generated content.
>
> --
> 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/7e36ded7-2f3d-43c2-881c-cbc75c80b5c2n%40googlegroups.com
> 
> .
>


-- 
-- 
==
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell   021 521 353
da...@kawhai.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/CALzH9quw5tSNNuAe%2Bspt9edTcJWV_ckUqdiyEtW5Qybx9kFepQ%40mail.gmail.com.

Instance Based Management?

[Matthew Amstutz]

Hello, I was wondering about instance based management. If I'm wrong, 
please tell me. 

When we have users and user generated content in a large database, query 
times are increased significantly. Why is there no instance based manager 
(like the models.Manager()) that basically generates a table for each user 
and queries ONLY that table? Would that not just flatten the database 
instead of increasing it's size? For example, if we have 1,000,000 users 
all of which generate at least 10 posts per day and one of the users only 
generates 5 in the span of 10 days, unless we have a many to many field or 
something to hold those five posts, the query time to find their posts 
would be ridiculous.

So if we have a table generated for each user that holds arbitrary 
connections to anything they generate, it would in theory cut query times 
significantly. Why is there no feature like this? Again, if I'm wrong 
please tell me but the amount of tables doesn't matter and instead the data 
they hold does so, in my understanding, 1,000,000,000 posts will always be 
the size of 1,000,000,000 posts no matter their organization.

I've got ideas on implementation and even asyncronous supports as well as 
customization but I have no idea how to bring this up to the django 
developers and I'm not even sure it would work (though, no matter how hard 
I try, I can't see anything wrong with it). 

Let me know your input and if there's a way I can ask the django devs about 
this and possibly even suggest a few things pertaining to it. I'd like to 
help make django the best it can be and if this works and we can implement 
it, django will be very fast with user generated content.

-- 
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/7e36ded7-2f3d-43c2-881c-cbc75c80b5c2n%40googlegroups.com.

Re: Pass existing model Instance to update_or_create callables

[Adam Johnson]

I think the scenario you're suggesting is just a little too complex for
update_or_create. It doesn't actually fetch the updated model instance .
You can instead write out what you want without too much extra code using
get_or_create, ensuring there's a transaction and select_for_update() to
lock the object whilst you modify it:

with transaction.atomic():
obj, created =
Model.objects.select_for_update().get_or_create(key=some_key,
defaults={"json_field": fresh_json})
if not created:
obj.json_field = merge_json(obj.json_field, fresh_json)
obj.save()

If you look inside update_or_create you'll see it essentially does this
already. If you use the pattern frequently, you can always wrap it up in
your own method.

On Mon, 26 Oct 2020 at 18:23, James Pulec  wrote:

> Since update_or_create supports callables in the defaults dictionary, I'm
> wondering if it's worth considering passing the existing instance (if one
> is found) to those callables when resolving them.
>
> The scenario I'm running into involves wanting to merge json data.
> Basically, I have a JSON field on the model that I'd like to do an
> update_or_create for, but in the case where there's an existing instance
> and I'd be performing an update, I'd like the merge the existing JSON data
> with the data I'm passing to my defaults.
>
> One way I can imagine solving for this case is to pass the existing model
> instance to callables defined in the defaults dictionary, if an existing
> model instance is found.
>
> This does feel a little gross, since you'll need to check if the passed
> value is None, so definitely open to other suggestion.s.
>
> Wanted to post this here before on Trac to see if there's interest, better
> solutions, or any concerns.
>
> Thanks!
>
> --
> 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/f44a3f50-1d01-467f-988e-8d43537a8f98n%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2F8S_3kAdvb9JRH2V9y4BE%2BJSCXkXDGDrX8HPpe2B69Q%40mail.gmail.com.

Re: Improved labels for M2M relations

[Adam Johnson]

Hi Julian

It should be noted that you can improve the display today by creating
explicit through models. However this is more longwinded.

This change does look like a neat usability improvement to me. It can also
help with debugging as the label appears in the default str/repr. My main
question is, does this not trigger migrations on user projects?

Thanks,

Adam

On Mon, 26 Oct 2020 at 16:28, Julian Klotz  wrote:

>
> Hey there,
>
> here’s a little topic that impacts the usability of Django admin’s delete
> views.
>
> When deleting an object using django admin, you get a nice summary of all
> deleted objects.
> I really like the overview, but the labels used to describe m2m relations
> that will be deleted aren't user-friendly at all:
>
> […]
>
>- MediaItem-subseries-relation: MediaItem_sub_series_relation object
>(11482)
>- MediaItem-piece-relation: MediaItem_pieces_relation object (11773)
>
> So I’d like to improve the labels a bit, using the from and to model’s
> verbose names. This can be easily accomplished by changing
> `create_many_to_many_intermediary_model` in fields/related.py.
>
> To be honest, I don’t know how to update the tests for something rooted
> deeply in Django’s core.Is anyone who is more competent than me interested
> in fixing this? It would greatly improve the “delete confirmation“ views.
>
> Here’s what I’ve got so for; it only fixes the model’s verbose name, not
> its string presentation.
>
> Best regards
> Julian
>
>
> […]
> to = make_model_tuple(to_model)[1]
> from_ = klass._meta.model_name
>
> if isinstance(to_model, str):
> to_label = to
> to_label_plural = to
> else:
> to_label = to_model._meta.verbose_name
> to_label_plural = to_model._meta.verbose_name_plural
>
> from_label = klass._meta.verbose_name
> from_label_plural = klass._meta.verbose_name_plural
>
> if to == from_:
> to = 'to_%s' % to
> from_ = 'from_%s' % from_
>
> meta = type('Meta', (), {
> 'db_table': field._get_m2m_db_table(klass._meta),
> 'auto_created': klass,
> 'app_label': klass._meta.app_label,
> 'db_tablespace': klass._meta.db_tablespace,
> 'unique_together': (from_, to),
> 'verbose_name': _('%(from)s-%(to)s relationship') % {'from':
> from_label, 'to': to_label},
> 'verbose_name_plural': _('%(from)s-%(to)s relationships') %
> {'from': from_label_plural, 'to': to_label_plural},
> 'apps': field.model._meta.apps,
> })
>
>
> --
> 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/69b6f2e0-8f0e-4cd0-b608-46fb9040b355n%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1cTKFXObortmGS3uevSA_6h4s%3Dyb4Yk8R1atooOMffpA%40mail.gmail.com.

Pass existing model Instance to update_or_create callables

[James Pulec]

Since update_or_create supports callables in the defaults dictionary, I'm 
wondering if it's worth considering passing the existing instance (if one 
is found) to those callables when resolving them.

The scenario I'm running into involves wanting to merge json data. 
Basically, I have a JSON field on the model that I'd like to do an 
update_or_create for, but in the case where there's an existing instance 
and I'd be performing an update, I'd like the merge the existing JSON data 
with the data I'm passing to my defaults.

One way I can imagine solving for this case is to pass the existing model 
instance to callables defined in the defaults dictionary, if an existing 
model instance is found.

This does feel a little gross, since you'll need to check if the passed 
value is None, so definitely open to other suggestion.s.

Wanted to post this here before on Trac to see if there's interest, better 
solutions, or any concerns.

Thanks!

-- 
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/f44a3f50-1d01-467f-988e-8d43537a8f98n%40googlegroups.com.

Improved labels for M2M relations

[Julian Klotz]

Hey there,

here’s a little topic that impacts the usability of Django admin’s delete 
views.

When deleting an object using django admin, you get a nice summary of all 
deleted objects.
I really like the overview, but the labels used to describe m2m relations 
that will be deleted aren't user-friendly at all:

[…]

   - MediaItem-subseries-relation: MediaItem_sub_series_relation object 
   (11482)
   - MediaItem-piece-relation: MediaItem_pieces_relation object (11773)

So I’d like to improve the labels a bit, using the from and to model’s 
verbose names. This can be easily accomplished by changing 
`create_many_to_many_intermediary_model` in fields/related.py.

To be honest, I don’t know how to update the tests for something rooted 
deeply in Django’s core.Is anyone who is more competent than me interested 
in fixing this? It would greatly improve the “delete confirmation“ views.

Here’s what I’ve got so for; it only fixes the model’s verbose name, not 
its string presentation.

Best regards
Julian


[…]
to = make_model_tuple(to_model)[1]
from_ = klass._meta.model_name

if isinstance(to_model, str):
to_label = to
to_label_plural = to
else:
to_label = to_model._meta.verbose_name
to_label_plural = to_model._meta.verbose_name_plural

from_label = klass._meta.verbose_name
from_label_plural = klass._meta.verbose_name_plural

if to == from_:
to = 'to_%s' % to
from_ = 'from_%s' % from_

meta = type('Meta', (), {
'db_table': field._get_m2m_db_table(klass._meta),
'auto_created': klass,
'app_label': klass._meta.app_label,
'db_tablespace': klass._meta.db_tablespace,
'unique_together': (from_, to),
'verbose_name': _('%(from)s-%(to)s relationship') % {'from': 
from_label, 'to': to_label},
'verbose_name_plural': _('%(from)s-%(to)s relationships') % 
{'from': from_label_plural, 'to': to_label_plural},
'apps': field.model._meta.apps,
})


-- 
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/69b6f2e0-8f0e-4cd0-b608-46fb9040b355n%40googlegroups.com.

Re: DB persistent connection

[Florian Apolloner]

Hi,

I am not sure what you are trying to tell us?! Opening a connection to 
Postgresql is somewhat time-consuming and 10ms in a cloud env does not seem 
to be surprising at all.

Cheers,
Florian

On Monday, October 26, 2020 at 2:28:28 PM UTC+1 pra...@fampay.in wrote:

> https://groups.google.com/g/django-developers/c/rH0QQP7tI6w/m/yBusiFTNBR4J
>
> We are running django with gunicorn + gevent. We have set Max con age to 
> 10 min. We use newrelic for monitoring. 
>
> Even though we have set it to use persistent connection it;s showing in 
> new relic that
> On average it takes 10ms for db connection
> [image: Screenshot 2020-10-26 at 3.54.08 PM.png]
>

-- 
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/5130fcd5-5f2e-485e-b784-c8c6c9ef05b6n%40googlegroups.com.

DB persistent connection

['Pratik Gajjar' via Django developers (Contributions to Django itself)]

https://groups.google.com/g/django-developers/c/rH0QQP7tI6w/m/yBusiFTNBR4J

We are running django with gunicorn + gevent. We have set Max con age to 10 
min. We use newrelic for monitoring. 

Even though we have set it to use persistent connection it;s showing in new 
relic that
On average it takes 10ms for db connection
[image: Screenshot 2020-10-26 at 3.54.08 PM.png]

-- 
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/8a382a84-4b5b-4a6c-9e87-1df3e1ba586cn%40googlegroups.com.