Re: Fellow Reports -- October 2020

[Carlton Gibson]

Hi all. 


Calendar Week 43 -- ending 25 October.


Triaged:

https://code.djangoproject.com/ticket/32131 -- ManifestStaticFilesStorage 
should also check in debug mode whether referenced file actually exists 
(wontfix)
https://code.djangoproject.com/ticket/32129 -- Confusing documentation on 
how to get cookie's time until it expires in seconds. (Accepted)
https://code.djangoproject.com/ticket/32125 -- Added basic support for 

Re: Improved labels for M2M relations

[Julian Klotz]

Hi Adam,

thanks for picking this up so quickly.
I considered setting custom “through” models to set verbose name and 
__str__, but I currently can’t “afford” changing all m2m fields throught 
the application.

Here’s the feedback I got concerning the usability issues (e.g. for 
MediaItem_pieces_relation object (11773))

   - Some people thought “11773” was the number of objects to be deleted, 
   even though the UI clearly states something else – it isn’t obvious for 
   some people that relations have their own IDs
   - People asked where they could change the (then-deleted) relation to a 
   different object
   


*It can also help with debugging as the label appears in the default 
str/repr.*
Thanks for giving me that hint. It’s the __str__ method of models.Model. 
Changing the default string presentation may be dangerous and also too 
generic. It would make sense to define a custom to-string method in 
`create_many_to_many_intermediary_model` (fields/related.py)*.*
Instead of showing *MediaItem_pieces_relation object (11773),* something 
like “Media Item-Piece relation, ID: 11773) would be good*; *moreover, it 
may be a good idea to show the “from” model’s edit link to point people to 
the place where they can change this relation.

*My main question is, does this not trigger migrations on user projects?*
Good point. I just checked – interestingly, neither changing the verbose 
name nor the __str__ method triggers new migrations 🥳



Best regards
Julian

Adam Johnson schrieb am Montag, 26. Oktober 2020 um 19:56:15 UTC+1:

> 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-develop...@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,

Re: Improved labels for M2M relations

[Julian Klotz]

… one last thought:

The verbose name could be: “Media Item-Piece relation”
The string presentation could be: “Relation to ”, e.g. “Relation to Piece xyz”

Together: 
*Media Item-Piece relation: Relation to Piece xyz (ID: 11773)*


Julian Klotz schrieb am Dienstag, 27. Oktober 2020 um 09:30:59 UTC+1:

> Hi Adam,
>
> thanks for picking this up so quickly.
> I considered setting custom “through” models to set verbose name and 
> __str__, but I currently can’t “afford” changing all m2m fields throught 
> the application.
>
> Here’s the feedback I got concerning the usability issues (e.g. for 
> MediaItem_pieces_relation object (11773))
>
>- Some people thought “11773” was the number of objects to be deleted, 
>even though the UI clearly states something else – it isn’t obvious for 
>some people that relations have their own IDs
>- People asked where they could change the (then-deleted) relation to 
>a different object
>
>
>
> *It can also help with debugging as the label appears in the default 
> str/repr.*
> Thanks for giving me that hint. It’s the __str__ method of models.Model. 
> Changing the default string presentation may be dangerous and also too 
> generic. It would make sense to define a custom to-string method in 
> `create_many_to_many_intermediary_model` (fields/related.py)*.*
> Instead of showing *MediaItem_pieces_relation object (11773),* something 
> like “Media Item-Piece relation, ID: 11773) would be good*; *moreover, it 
> may be a good idea to show the “from” model’s edit link to point people to 
> the place where they can change this relation.
>
> *My main question is, does this not trigger migrations on user projects?*
> Good point. I just checked – interestingly, neither changing the verbose 
> name nor the __str__ method triggers new migrations 🥳
>
>
>
> Best regards
> Julian
>
> Adam Johnson schrieb am Montag, 26. Oktober 2020 um 19:56:15 UTC+1:
>
>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/djan

Re: Instance Based Management?

[Tom Forbes]

I think what Mathew really wants is support for table partitioning. You can get 
this right now with this library[1] for postgres. I’m not sure if this makes 
sense to add to core, however support is quite broad (MYSQL, MariaDB, Postgres 
and Oracle).

1. 
https://django-postgres-extra.readthedocs.io/en/master/table_partitioning.html

Tom

> On 27 Oct 2020, at 05:30, Jure Erznožnik  wrote:
> 
> 
> 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.

-- 
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/BA1C3DF2-3BD1-473F-BA01-016ACA251D5D%40tomforb.es.

Re: Instance Based Management?

[Matthew Amstutz]

The idea was to automatically generate a table with auto generated fields 
that gets arbitrarily connected to any content that can be spawned by 
usersThen I realized this is pretty much an M2M field with extra steps 
but it wouldn't let me delete the post lol. But I didn't know about table 
partitioning so Thank you for the information. I know about ContentTypes 
and such, I was just thinking it may be possible to cut some of the work 
out for the developer so instead of explicitly declaring fields, they can 
just access the existing one. Like I said, I realized this was stupid but 
the group wouldn't let me delete it lol.  Thanks again for the information 
and I only posted on this group because I thought the idea could be put in 
the core just to cut some of the work out for developers.

Thanks again everyone, sorry for the ridiculously stupid post lol (I swear 
I'm not 100% new)

On Tuesday, October 27, 2020 at 7:14:08 AM UTC-4 t...@tomforb.es wrote:

> I think what Mathew really wants is support for table partitioning. You 
> can get this right now with this library[1] for postgres. I’m not sure if 
> this makes sense to add to core, however support is quite broad (MYSQL, 
> MariaDB, Postgres and Oracle).
>
> 1. 
> https://django-postgres-extra.readthedocs.io/en/master/table_partitioning.html
>
> Tom
>
> On 27 Oct 2020, at 05:30, Jure Erznožnik  wrote:
>
>  
>
> Hi Matthew,
>
> I think you found the wrong mailing list for this question. Might I 
> suggest you try django...@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-develop...@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-develop...@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
>  
> 
> .
>
>

-- 
You received this message because you are

Re: Instance Based Management?

[Adam Johnson]

>
> Thanks again everyone, sorry for the ridiculously stupid post lol (I swear
> I'm not 100% new)


Self-insulting is not tolerated on this list! You're not stupid, nor was
your post. It's an interesting problem to have, thank you for posting.

If indexes aren't working, partitioning does seem to be the way to reach
high scale, and perhaps Django could do more to support it. If you try it
out and spot anything, do let us know if you can spot any improvements to
Django.



On Tue, 27 Oct 2020 at 14:57, Matthew Amstutz 
wrote:

> The idea was to automatically generate a table with auto generated fields
> that gets arbitrarily connected to any content that can be spawned by
> usersThen I realized this is pretty much an M2M field with extra steps
> but it wouldn't let me delete the post lol. But I didn't know about table
> partitioning so Thank you for the information. I know about ContentTypes
> and such, I was just thinking it may be possible to cut some of the work
> out for the developer so instead of explicitly declaring fields, they can
> just access the existing one. Like I said, I realized this was stupid but
> the group wouldn't let me delete it lol.  Thanks again for the information
> and I only posted on this group because I thought the idea could be put in
> the core just to cut some of the work out for developers.
>
> Thanks again everyone, sorry for the ridiculously stupid post lol (I swear
> I'm not 100% new)
>
> On Tuesday, October 27, 2020 at 7:14:08 AM UTC-4 t...@tomforb.es wrote:
>
>> I think what Mathew really wants is support for table partitioning. You
>> can get this right now with this library[1] for postgres. I’m not sure if
>> this makes sense to add to core, however support is quite broad (MYSQL,
>> MariaDB, Postgres and Oracle).
>>
>> 1.
>> https://django-postgres-extra.readthedocs.io/en/master/table_partitioning.html
>>
>> Tom
>>
>> On 27 Oct 2020, at 05:30, Jure Erznožnik  wrote:
>>
>> 
>>
>> Hi Matthew,
>>
>> I think you found the wrong mailing list for this question. Might I
>> suggest you try django...@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-develop...@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

Re: Instance Based Management?

[Matthew Amstutz]

Thanks Adam! I'll do some experimenting and see what I can come up with!
Also, I'll stop insulting myself lol. I wasn't expecting such polite
replies, everyone has been telling me that alot of developers are mean to
newbies.

 I've been coding for 2 years and using django for a year and a half; I've
got alot of ideas to try and make things easier for developers but
experimentation is going to be the most important thing for it. I'll try
and get some data before posting next time.

Thanks again!

On Tue, Oct 27, 2020, 11:11 AM Adam Johnson  wrote:

> Thanks again everyone, sorry for the ridiculously stupid post lol (I swear
>> I'm not 100% new)
>
>
> Self-insulting is not tolerated on this list! You're not stupid, nor was
> your post. It's an interesting problem to have, thank you for posting.
>
> If indexes aren't working, partitioning does seem to be the way to reach
> high scale, and perhaps Django could do more to support it. If you try it
> out and spot anything, do let us know if you can spot any improvements to
> Django.
>
>
>
> On Tue, 27 Oct 2020 at 14:57, Matthew Amstutz 
> wrote:
>
>> The idea was to automatically generate a table with auto generated fields
>> that gets arbitrarily connected to any content that can be spawned by
>> usersThen I realized this is pretty much an M2M field with extra steps
>> but it wouldn't let me delete the post lol. But I didn't know about table
>> partitioning so Thank you for the information. I know about ContentTypes
>> and such, I was just thinking it may be possible to cut some of the work
>> out for the developer so instead of explicitly declaring fields, they can
>> just access the existing one. Like I said, I realized this was stupid but
>> the group wouldn't let me delete it lol.  Thanks again for the information
>> and I only posted on this group because I thought the idea could be put in
>> the core just to cut some of the work out for developers.
>>
>> Thanks again everyone, sorry for the ridiculously stupid post lol (I
>> swear I'm not 100% new)
>>
>> On Tuesday, October 27, 2020 at 7:14:08 AM UTC-4 t...@tomforb.es wrote:
>>
>>> I think what Mathew really wants is support for table partitioning. You
>>> can get this right now with this library[1] for postgres. I’m not sure if
>>> this makes sense to add to core, however support is quite broad (MYSQL,
>>> MariaDB, Postgres and Oracle).
>>>
>>> 1.
>>> https://django-postgres-extra.readthedocs.io/en/master/table_partitioning.html
>>>
>>> Tom
>>>
>>> On 27 Oct 2020, at 05:30, Jure Erznožnik  wrote:
>>>
>>> 
>>>
>>> Hi Matthew,
>>>
>>> I think you found the wrong mailing list for this question. Might I
>>> suggest you try django...@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