Hi all, On Wed, Feb 10, 2016, at 19:38, Tim Graham wrote: > I'm not sure. Did you find this past discussion: > https://groups.google.com/d/topic/django-developers/tSLuqu0UFrY/discussion > ? The idea was also mentioned a month ago with no replies: > https://groups.google.com/d/topic/django-developers/Ov91x7AXwmM/discussion
Sorry, I failed to find that. Most external links seem to be broken, sadly, but, more importantly: the discussion seemed to reach an end with no final decision. > > Are you a maintainer of django-polymorphic? What's the advantage of > bringing it into core as opposed to keeping it as an external project? I am not. I have submited a few PRs though, and did the django1.9- compatibility work, but I'm not a maintainer. On Wed, Feb 10, 2016, at 21:39, Cristiano Coelho wrote: > How's the performance of django-polymorphic compared to using select_related of childs of interest and then handle them manually in the code with hasattr ? Does it resolve to multiple joins as the select_related option, or does it perform multiple queries? Inheritance using multiple tables is always a big headache :( django_polymorphic executes 1+N queries, where N is the amount of subclasses all the selected objects have (NOT the amount of objects). So if you had: class Venue(models.Model): pass class Restaurant(Venue): pass class ParkingLot(Venue): pass Selecting objects would perform *at most* 3 queries (and would perform only 1 if all objects are of class Venue). (I know, it's a bad real- life example). I'd avoid touching the default queryset, and actually add an option `.polymorphic` like: Venue.objects.polymorphic.filter(is_real=False) so the default behaviour does not change. In regards to performance of django_polymorphic vs `select_related`, the latter is probably more performance, but the code would probably be a lot cleaner for the former. Note that it's not just about object fields, but also it's class (which can include additional methods on each child, or overloaded methods). On Wed, Feb 10, 2016, at 22:13, Curtis Maloney wrote: > > [...] > > As I recall it, the general approach here is: is there a reason this > can't live as a 3rd party app? > Mostly, increased simplicity in maintenance, code, and following the latest django release. The current approach extends lots of django classes in an external module to alter them, which isn't generally very clean. I also get a feeling that this is a very sought after feature in django. > Would it benefit significantly by being more deeply integrated into > core, and if so, does it bring sufficient benefit to users to warrant > the changes? > I'm interested in performing the changes myself (in case you wonder about the effort in it). Benefits to end-user are the fact that polymorphic features won't ever lag behind master/latest-stable (BEING part of it), and more simplicity in dealing with polymorphic models (even simpler than configuring a separate app). > There was some research by Sebastian Vetter on "single-child auto- > resolve" solutions for MTI and how they scaled (from memory, model- > utils' InheritanceManager, polymorphic, and generic-m2m) > https://github.com/elbaschid/mti-lightbulb > Django already uses MTI. The only difference I'm proposing is, basically, making life simpler for those wanting to get all objects as their native class, rather than parent class (while not affecting those that don't use them). -- Hugo Osvaldo Barrera -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1455163500.203076.518006514.3A0C70DC%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
