Re: Django & django-polymorphic

[Curtis Maloney]

On 11/02/16 15:05, 'Hugo Osvaldo Barrera' via Django developers 
(Contributions to Django itself) wrote:

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


I know Django uses MTI.  This thread is, after all, talking about a tool 
for a _specific_ use case of MTI.


This investigation was specifically comparing the _scalability_ of 3 
solutions to the same problem.


The implementations differ as:

polymorphic:
- has a "hidden" content_type field to indicate which child model to 
link for this "parent" record

- uses prefetch_related to resolve
- results in 1+N queries

InheritanceManager (admin-tools):-
- uses select_related to grab _all_ the child models
- selects the first one that exists
- always results in 1 query
- can blow your DB server's brains out with the number of joins (if you 
have a couple of hundred child models).

- can select the "wrong" child if you somehow made two for the same parent

Generic M2M:
- quite a different solution, but could be used in the same way for 
Seb's purposes.

- don't recall specifics
- scaled dramatically better than the other two


--
C

--
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/56BC2770.1090707%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django & django-polymorphic

['Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself)]

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.

Re: Lazy operations refactor regression with abstract models #25858

[Alex Hill]

It looks like we agree that this depending on import order is not on, so we 
have no choice but to break behaviour in some cases.

Option 1 (don't allow relative references) removes support for relative 
references in abstract models for everyone.

Option 2 (resolve references relative to the first concrete inheriting 
class) doesn't remove anybody's existing behaviour, just formalises it and 
clarifies how it's specified. The most anybody has to do to keep doing what 
they're doing is add an app label to a reference.

Option 3 (always resolve references relative to the abstract model) makes 
impossible something that is currently possible: resolving relative 
references in the concrete class's app.

I like option 2. Being able to define a "floating" reference to a 
to-be-implemented model in a different app is a useful feature in abstract 
models.

If we can't agree on that, I'd go with option 1. I don't really see 
abstract models as belonging to an app in the same way concrete models do, 
and that's reflected in Django in various ways. They're not recognised as 
models by the app registry, fields in their concrete subclasses belong to 
the inheriting class (unlike in concrete inheritance), we have app label 
placeholders for related names, etc. I see them more as a blueprint or 
template than a model. Options 1 and 2 both reinforce that distinction, 
option 3 muddies it a bit.

Cheers,
Alex


On Thursday, February 11, 2016 at 5:29:52 AM UTC+8, charettes wrote:
>
> I should have mentioned that this behavior is reproducible since at least
> Django 1.6 and has not been introduced by Django 1.8. I wouldn't be 
> surprised
> if it has always been working before the fix was introduced.
>
> Still, as you mentionned the conditions required to achieve this were 
> really
> convoluted before the lazy operations refactor.
>
> Simon
>
> Le mercredi 10 février 2016 16:11:43 UTC-5, Shai Berger a écrit :
>>
>> On Tuesday 09 February 2016 23:33:50 charettes wrote: 
>> > Hi everyone, 
>> > 
>> > The chosen fix[1] unfortunately introduced a new regression[2]. 
>> > 
>> > It looks like the behavior described in the previous ticket was 
>> possible 
>> > with 
>> > Django 1.8 under certain circumstances[3] where the abstract models 
>> defined 
>> > in a foreign application were derived as concrete models in another 
>> > applications 
>> > before the abstract models relations are resolved (if they are ever 
>> > resolved): 
>> > 
>>
>> The explanation is complex enough, the case where it works edgy enough, 
>> that 
>> I'd be content to call this a bug in 1.8. I'm pretty sure the specifics 
>> of this 
>> resolution are not documented, and my sense from reading the ticket is 
>> that if 
>> you'd try to document the behavior you'll reach the conclusion that it 
>> probably isn't intentional. 
>>
>> My 2 cents, 
>> Shai. 
>>
>> > 
>> > [1] 
>> https://github.com/django/django/commit/bc7d201bdbaeac14a49f51a9ef292d6 
>> > [2] https://code.djangoproject.com/ticket/26186 
>> > [3] https://code.djangoproject.com/ticket/26186#comment:8 
>> > [4] https://code.djangoproject.com/ticket/24215 
>>
>

-- 
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/ac07321f-aa6a-47dc-b0f1-d49ba9b71d1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Curtis Maloney]

On 11/02/16 00:55, Andy Baker wrote:

I can't help but feel that the "admin is very rudimentary and hard to
customize" is perpetually overplayed by many in the community. Maybe I'm
suffering Stockholm Syndrome but I'd like to raise a dissenting voice.


I must admit I'm a large proponent of warning against getting caught up 
in "Admin as my management console".


As customisable as it can be, I find the problem to be it is a 
data-centric view of your system, closely tied to the database models.


IMHO a management interface for site should be a _process_ centric view, 
abstracting away the implementation details of tables and fields.


Perhaps a better way to think of it as the difference between a 
"management" and a "maintenance" interface.


True, in a lot of cases these can be the same thing, and for simpler 
sites Admin works "just fine".  However, I've been on too many projects 
that wind up spending a lot of time and effort customising Admin to do 
things that would have been simpler in a custom view.


Worse still, I've seen projects alter their schema design to accommodate 
Admin's limitations [like lack of nested inlines]


Is it possible to add other views to admin?  Sure... though it's not 
clear, or well documented.


Can documentation alone overcome this problem?  I'm not convinced it can.

For some years now I've been proposing an investigation into slicing 
Admin into two layers: a base "management interface framework" layer, 
and "admin" built atop this framework.


Then we can keep providing the Admin we all know and love, and also make 
it easier for people to build their own management interfaces.


However, I don't currently have the time [or admin familiarity] to 
undertake this work.


--
Curtis

--
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/56BBE4BB.3060805%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Dheerendra Rathor]

On Wed, 10 Feb 2016 at 13:55 Andy Baker  wrote:

> I can't help but feel that the "admin is very rudimentary and hard to
> customize" is perpetually overplayed by many in the community. Maybe I'm
> suffering Stockholm Syndrome but I'd like to raise a dissenting voice.
>
> I find it the quickest and most efficient way to provide an admin
> interface for staff users. It's remarkably easy to customize in my view
> (and I've done a heck of a lot of it). If it didn't exist I'd have to
> invent something damn similar. :)
>
> More importantly - it's not an either/or decision. I always recommend
> starting with the admin - use the available hooks and means of
> customization and when you really, truely hit a brick wall - then remember
> "It's just Django" - drop down to a custom view that uses the admin base
> templates and CSS and easily integrates with other admin pages. The beauty
> of this is that you can carry on using the admin for everything else where
> it still provides easy wins.
>
> Warning people away means they are less likely to discover the many simple
> customization hooks and they are more likely to spend time reinventing the
> wheel.
>
> If the admin was truly as limited as some make it out to be, then one of
> the many attempts to replace it would have gained momentum. I'm not saying
> it couldn't be replaced with something better - but it's far from being
> something we should cover in warnings and caveats.
>
> Sigh. I perpetually intend to write tutorials to help demystify admin
> customization - but I've sadly perpetually failed to find the time...
>

It comes to my  mind many times to create a video tutorial for advance
Django including customizing admin and other advance part of Django like
complex querysets (with F, Q etc).
We can work together on this to create nice tutorials.

On Tuesday, 9 February 2016 23:25:20 UTC, Tim Graham wrote:
>>
>> The introduction to the admin in the docs [0] reads:
>>
>> "One of the most powerful parts of Django is the automatic admin
>>> interface. It reads metadata in your model to provide a powerful and
>>> production-ready interface that content producers can immediately use to
>>> start adding content to the site."
>>>
>>
>> I've proposed [1] changing it to:
>>
>> "One of the most powerful parts of Django is the automatic admin
>>> interface. It reads metadata from your models to provide a quick and
>>> rudimentary interface where trusted users can manage content on your site.
>>>
>>>
>>> The admin has many hooks for customization but beware of trying to use
>>> those hooks exclusively. If your needs outgrow what the admin provides, it
>>> may be simpler to write your own views. The admin’s recommended use is as
>>> an organization’s internal management tool. It’s not intended for building
>>> your entire front end around."
>>>
>>
>> However several reviewers have made comments like "I worry that the
>> description of the Admin sells it short. The Admin is actually brilliant
>> kit and works as advertised." and "Downgrading Django's admin from
>> "powerful and production ready" to "quick and dirty [old wording]" is very
>> harsh... And I fear this will not only lower user's expectations, but also
>> dev's carefulness!"
>>
>> I think part of the reason I raise this is that I'm getting weary of
>> adding hook after hook for customizing every little thing. I worry we'll
>> end up with an unmaintainable mess at some point. The latest proposal that
>> has me thinking about this adds ModelAdmin.orderable_by and 
>> ModelAdmin.get_orderable_by()
>> for the use case of disabling sorting of a column in the change list [2].
>> This topic also came up in the discussion of whether or not to add
>> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done
>> yet). There's also an open question about whether or not to add a view
>> permission [4]. I don't want to discuss each of these decisions on this
>> thread but rather the broader question of whether putting a lot of effort
>> in this area is a direction we should pursue. I know there have been some
>> proposals of "admin2" but realistically I think the admin has too many
>> customizations points such that superseding it with something new and
>> innovative won't be feasible from a backwards compatibility standpoint.
>>
>> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
>> [1] https://github.com/django/django/pull/6104
>> [2] https://github.com/django/django/pull/6107
>> [3]
>> https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
>> [4]
>> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion
>>
> --
> 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 

Re: Django & django-polymorphic

[Curtis Maloney]

On 11/02/16 09:22, 'Hugo Osvaldo Barrera' via Django developers 
(Contributions to Django itself) wrote:

Hi there,

I'd love to see some (most?) of the features from django-polymorphic on
django itself. I'm very much be willing to work on this myself. Of
course, there's several details that need to be discussed too, HOWEVER,
but before I even start, I'd like to know if they'd even be acceptable
in django, or, for some reason, the functionality has been kept out of
django-core.


As I recall it, the general approach here is:  is there a reason this 
can't live as a 3rd party app?


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?


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


--
Curtis

--
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/56BBE052.8000205%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django & django-polymorphic

[Tim Graham]

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

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?

This is the correct place for the discussion (non-trivial design decisions).

On Wednesday, February 10, 2016 at 5:22:30 PM UTC-5, Hugo Osvaldo Barrera 
wrote:
>
> Hi there, 
>
> I'd love to see some (most?) of the features from django-polymorphic on 
> django itself. I'm very much be willing to work on this myself. Of 
> course, there's several details that need to be discussed too, HOWEVER, 
> but before I even start, I'd like to know if they'd even be acceptable 
> in django, or, for some reason, the functionality has been kept out of 
> django-core. 
>
> Would a well designed PR to incorporate this be acceptable? Is it worth 
> opening a discussion? Or has this been rejected before, and my searching 
> skills failed me? 
>
> Also on this topic; should this discussion be opened here, or rather as 
> an issue over at code.djangoproject.com? 
>
> Thanks, 
>
> -- 
> 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/87e7c36b-d725-4efd-be4b-a2a035a90c3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django & django-polymorphic

['Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself)]

Hi there,

I'd love to see some (most?) of the features from django-polymorphic on
django itself. I'm very much be willing to work on this myself. Of
course, there's several details that need to be discussed too, HOWEVER,
but before I even start, I'd like to know if they'd even be acceptable
in django, or, for some reason, the functionality has been kept out of
django-core.

Would a well designed PR to incorporate this be acceptable? Is it worth
opening a discussion? Or has this been rejected before, and my searching
skills failed me?

Also on this topic; should this discussion be opened here, or rather as
an issue over at code.djangoproject.com?

Thanks,

-- 
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/1455142930.124280.51786.41BED838%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Tim Graham]

Is salted SHA1 sufficiently insecure to remove it from the default 
PASSWORD_HASHERS or should we leave it for now? Any project created before 
pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1 
hashes unless all their users have logged in since. I've written 
instructions on how to upgrade such passwords without requiring all your 
users to login [1]. If it's warranted, we could make a blog post advising 
this. 

[1] https://github.com/django/django/pull/6114

On Monday, February 8, 2016 at 3:12:28 PM UTC-5, Tim Graham wrote:
>
> Thanks for the feedback everyone. I've created a few action items:
>
> https://code.djangoproject.com/ticket/26187 - Remove weak password 
> hashers from the default PASSWORD_HASHERS setting
> https://code.djangoproject.com/ticket/26188 - Document how to wrap 
> password hashers
> https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
> password hasher to upgrade SHA1 passwords
>
> On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>>
>> I kept meaning to weigh in on this... but all my points have been made. 
>>
>> It sounds like the middle ground is to: 
>>
>> 1) remove them from the default list 
>> 2) keep them in the codebase 
>> 3) make them noisy (raise warnings) 
>> 4) provide docs/tools on how to upgrade 
>>
>> Then we get "secure by default" (1), as well as "encouraging upgrades" 
>> (3), whilst also "supporting slow-to-update installs" (4), and 
>> "encouraging best practices" (3). 
>>
>>
>> -- 
>> C 
>>
>>
>> On 06/02/16 19:51, Aymeric Augustin wrote: 
>> > Yes, that would be good from the “security by default” standpoint. This 
>> > would also allow us to trim the full list of hashers which is repeated 
>> > several times in the docs. 
>> > 
>> > -- 
>> > Aymeric. 
>> > 
>> >> On 6 févr. 2016, at 00:03, Tim Graham > >> > wrote: 
>> >> 
>> >> I would guess most users aren't customizing the default list of 
>> >> hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS 
>> >> setting and let anyone who needs to use a weak hasher define their own 
>> >> setting (at which point a warning probably isn't needed). Does that 
>> >> seem okay? 
>> >> 
>> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
>> wrote: 
>> >> 
>> >> Adding a check for weak password hashers could be a good 
>> >> compromise to drive attention to the issue but make it reasonably 
>> >> easy to ignore it if you need MD5 for compatibility with other 
>> >> systems. 
>> >> 
>> >> -- 
>> >> Aymeric. 
>> >> 
>> >>> On 5 févr. 2016, at 21:11, Sergei Maertens > >>> > wrote: 
>> >>> 
>> >>> This is my main concern as well. I often migrate old Joomla or 
>> >>> other PHP things that use md5, and it's really convenient that 
>> >>> Django upgrades the passwords for free for me. 
>> >>> 
>> >>> Although I guess I could just write the hasher as part of the 
>> >>> project and add it to the setting, but then that's an additional 
>> >>> burding because you need to keep track of potential new hashers 
>> >>> that get added in the default settings. 
>> >>> 
>> >>> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń 
>> wrote: 
>> >>> 
>> >>> Will I still be able to implement unsalted hasher if I so 
>> desire? 
>> >>> 
>> >>> Don't get me wrong, I understand thats pretty crappy way to 
>> >>> store password, but there are times when you inherit large 
>> >>> set of data from site that you are moving from some old PHP 
>> >>> contraption that happens to be around since 2006, is big 
>> >>> (>100 users), ran by company that dominates one of 
>> >>> nation's markets and says "absolutely no" on making all those 
>> >>> housewifes reset passwords, and your passwords happen to use 
>> >>> md5(md5(pass) + md5(pass)) for passwords? 
>> >>> 
>> >>> 
>> >>> -- 
>> >>> 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 post to this group, send email to django-d...@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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com
>>  
>> >>> <
>> https://groups.google.com/d/msgid/django-developers/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com?utm_medium=email_source=footer>.
>>  
>>
>> >>> For more options, visit 

Re: Lazy operations refactor regression with abstract models #25858

[charettes]

I should have mentioned that this behavior is reproducible since at least
Django 1.6 and has not been introduced by Django 1.8. I wouldn't be 
surprised
if it has always been working before the fix was introduced.

Still, as you mentionned the conditions required to achieve this were really
convoluted before the lazy operations refactor.

Simon

Le mercredi 10 février 2016 16:11:43 UTC-5, Shai Berger a écrit :
>
> On Tuesday 09 February 2016 23:33:50 charettes wrote: 
> > Hi everyone, 
> > 
> > The chosen fix[1] unfortunately introduced a new regression[2]. 
> > 
> > It looks like the behavior described in the previous ticket was possible 
> > with 
> > Django 1.8 under certain circumstances[3] where the abstract models 
> defined 
> > in a foreign application were derived as concrete models in another 
> > applications 
> > before the abstract models relations are resolved (if they are ever 
> > resolved): 
> > 
>
> The explanation is complex enough, the case where it works edgy enough, 
> that 
> I'd be content to call this a bug in 1.8. I'm pretty sure the specifics of 
> this 
> resolution are not documented, and my sense from reading the ticket is 
> that if 
> you'd try to document the behavior you'll reach the conclusion that it 
> probably isn't intentional. 
>
> My 2 cents, 
> Shai. 
>
> > 
> > [1] 
> https://github.com/django/django/commit/bc7d201bdbaeac14a49f51a9ef292d6 
> > [2] https://code.djangoproject.com/ticket/26186 
> > [3] https://code.djangoproject.com/ticket/26186#comment:8 
> > [4] https://code.djangoproject.com/ticket/24215 
>

-- 
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/cbf4295f-9ee0-4c82-bcd2-af6de8031a7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Lazy operations refactor regression with abstract models #25858

[Shai Berger]

On Tuesday 09 February 2016 23:33:50 charettes wrote:
> Hi everyone,
> 
> The chosen fix[1] unfortunately introduced a new regression[2].
> 
> It looks like the behavior described in the previous ticket was possible
> with
> Django 1.8 under certain circumstances[3] where the abstract models defined
> in a foreign application were derived as concrete models in another
> applications
> before the abstract models relations are resolved (if they are ever
> resolved):
> 

The explanation is complex enough, the case where it works edgy enough, that 
I'd be content to call this a bug in 1.8. I'm pretty sure the specifics of this 
resolution are not documented, and my sense from reading the ticket is that if 
you'd try to document the behavior you'll reach the conclusion that it 
probably isn't intentional.

My 2 cents,
Shai.

> 
> [1] https://github.com/django/django/commit/bc7d201bdbaeac14a49f51a9ef292d6
> [2] https://code.djangoproject.com/ticket/26186
> [3] https://code.djangoproject.com/ticket/26186#comment:8
> [4] https://code.djangoproject.com/ticket/24215

Re: thinking about the admin's scope and its description in the docs

[Andy Baker]

Just to follow up - I think the biggest improvements I've yearned for are 
fairly simple and unlikely to break backwards compatibility:

1. Break up the remaining monolithic methods to allow easier overriding 
(this is much better nowadays but a few beasts remain)
2. More blocks in the templates or more includes - again to allow 
overriding. 

Also - If those parts of the admin that are unique to it and not merely 
aspects of ModelForms, CBVs and other generic Django features  could be 
broken out and made re-susable - then over time the admin could become 
simply an example of how more general Django features can be glued 
together. 

On Wednesday, 10 February 2016 13:55:02 UTC, Andy Baker wrote:
>
> I can't help but feel that the "admin is very rudimentary and hard to 
> customize" is perpetually overplayed by many in the community. Maybe I'm 
> suffering Stockholm Syndrome but I'd like to raise a dissenting voice.
>
> I find it the quickest and most efficient way to provide an admin 
> interface for staff users. It's remarkably easy to customize in my view 
> (and I've done a heck of a lot of it). If it didn't exist I'd have to 
> invent something damn similar. :)
>
> More importantly - it's not an either/or decision. I always recommend 
> starting with the admin - use the available hooks and means of 
> customization and when you really, truely hit a brick wall - then remember 
> "It's just Django" - drop down to a custom view that uses the admin base 
> templates and CSS and easily integrates with other admin pages. The beauty 
> of this is that you can carry on using the admin for everything else where 
> it still provides easy wins.
>
> Warning people away means they are less likely to discover the many simple 
> customization hooks and they are more likely to spend time reinventing the 
> wheel.
>
> If the admin was truly as limited as some make it out to be, then one of 
> the many attempts to replace it would have gained momentum. I'm not saying 
> it couldn't be replaced with something better - but it's far from being 
> something we should cover in warnings and caveats.
>
> Sigh. I perpetually intend to write tutorials to help demystify admin 
> customization - but I've sadly perpetually failed to find the time...
>
> On Tuesday, 9 February 2016 23:25:20 UTC, Tim Graham wrote:
>>
>> The introduction to the admin in the docs [0] reads:
>>
>> "One of the most powerful parts of Django is the automatic admin 
>>> interface. It reads metadata in your model to provide a powerful and 
>>> production-ready interface that content producers can immediately use to 
>>> start adding content to the site."
>>>
>>
>> I've proposed [1] changing it to:
>>
>> "One of the most powerful parts of Django is the automatic admin 
>>> interface. It reads metadata from your models to provide a quick and 
>>> rudimentary interface where trusted users can manage content on your site. 
>>>
>>>
>>> The admin has many hooks for customization but beware of trying to use 
>>> those hooks exclusively. If your needs outgrow what the admin provides, it 
>>> may be simpler to write your own views. The admin’s recommended use is as 
>>> an organization’s internal management tool. It’s not intended for building 
>>> your entire front end around."
>>>
>>
>> However several reviewers have made comments like "I worry that the 
>> description of the Admin sells it short. The Admin is actually brilliant 
>> kit and works as advertised." and "Downgrading Django's admin from 
>> "powerful and production ready" to "quick and dirty [old wording]" is very 
>> harsh... And I fear this will not only lower user's expectations, but also 
>> dev's carefulness!"
>>
>> I think part of the reason I raise this is that I'm getting weary of 
>> adding hook after hook for customizing every little thing. I worry we'll 
>> end up with an unmaintainable mess at some point. The latest proposal that 
>> has me thinking about this adds ModelAdmin.orderable_by and 
>> ModelAdmin.get_orderable_by() 
>> for the use case of disabling sorting of a column in the change list [2]. 
>> This topic also came up in the discussion of whether or not to add 
>> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done 
>> yet). There's also an open question about whether or not to add a view 
>> permission [4]. I don't want to discuss each of these decisions on this 
>> thread but rather the broader question of whether putting a lot of effort 
>> in this area is a direction we should pursue. I know there have been some 
>> proposals of "admin2" but realistically I think the admin has too many 
>> customizations points such that superseding it with something new and 
>> innovative won't be feasible from a backwards compatibility standpoint.
>>
>> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
>> [1] https://github.com/django/django/pull/6104
>> [2] https://github.com/django/django/pull/6107
>> [3] 
>> 

Re: thinking about the admin's scope and its description in the docs

[Andy Baker]

I can't help but feel that the "admin is very rudimentary and hard to 
customize" is perpetually overplayed by many in the community. Maybe I'm 
suffering Stockholm Syndrome but I'd like to raise a dissenting voice.

I find it the quickest and most efficient way to provide an admin interface 
for staff users. It's remarkably easy to customize in my view (and I've 
done a heck of a lot of it). If it didn't exist I'd have to invent 
something damn similar. :)

More importantly - it's not an either/or decision. I always recommend 
starting with the admin - use the available hooks and means of 
customization and when you really, truely hit a brick wall - then remember 
"It's just Django" - drop down to a custom view that uses the admin base 
templates and CSS and easily integrates with other admin pages. The beauty 
of this is that you can carry on using the admin for everything else where 
it still provides easy wins.

Warning people away means they are less likely to discover the many simple 
customization hooks and they are more likely to spend time reinventing the 
wheel.

If the admin was truly as limited as some make it out to be, then one of 
the many attempts to replace it would have gained momentum. I'm not saying 
it couldn't be replaced with something better - but it's far from being 
something we should cover in warnings and caveats.

Sigh. I perpetually intend to write tutorials to help demystify admin 
customization - but I've sadly perpetually failed to find the time...

On Tuesday, 9 February 2016 23:25:20 UTC, Tim Graham wrote:
>
> The introduction to the admin in the docs [0] reads:
>
> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata in your model to provide a powerful and 
>> production-ready interface that content producers can immediately use to 
>> start adding content to the site."
>>
>
> I've proposed [1] changing it to:
>
> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata from your models to provide a quick and 
>> rudimentary interface where trusted users can manage content on your site. 
>>
>>
>> The admin has many hooks for customization but beware of trying to use 
>> those hooks exclusively. If your needs outgrow what the admin provides, it 
>> may be simpler to write your own views. The admin’s recommended use is as 
>> an organization’s internal management tool. It’s not intended for building 
>> your entire front end around."
>>
>
> However several reviewers have made comments like "I worry that the 
> description of the Admin sells it short. The Admin is actually brilliant 
> kit and works as advertised." and "Downgrading Django's admin from 
> "powerful and production ready" to "quick and dirty [old wording]" is very 
> harsh... And I fear this will not only lower user's expectations, but also 
> dev's carefulness!"
>
> I think part of the reason I raise this is that I'm getting weary of 
> adding hook after hook for customizing every little thing. I worry we'll 
> end up with an unmaintainable mess at some point. The latest proposal that 
> has me thinking about this adds ModelAdmin.orderable_by and 
> ModelAdmin.get_orderable_by() 
> for the use case of disabling sorting of a column in the change list [2]. 
> This topic also came up in the discussion of whether or not to add 
> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done 
> yet). There's also an open question about whether or not to add a view 
> permission [4]. I don't want to discuss each of these decisions on this 
> thread but rather the broader question of whether putting a lot of effort 
> in this area is a direction we should pursue. I know there have been some 
> proposals of "admin2" but realistically I think the admin has too many 
> customizations points such that superseding it with something new and 
> innovative won't be feasible from a backwards compatibility standpoint.
>
> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
> [1] https://github.com/django/django/pull/6104
> [2] https://github.com/django/django/pull/6107
> [3] 
> https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
> [4] 
> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion
>

-- 
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/26f81439-3648-40cf-9a46-fceb5ccabba1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Dheerendra Rathor]

On Tue, 9 Feb 2016 at 23:25 Tim Graham  wrote:

> The introduction to the admin in the docs [0] reads:
>
> "One of the most powerful parts of Django is the automatic admin
>> interface. It reads metadata in your model to provide a powerful and
>> production-ready interface that content producers can immediately use to
>> start adding content to the site."
>>
>
> I've proposed [1] changing it to:
>
> "One of the most powerful parts of Django is the automatic admin
>> interface. It reads metadata from your models to provide a quick and
>> rudimentary interface where trusted users can manage content on your site.
>
>
How about quick and powerful?

> The admin has many hooks for customization but beware of trying to use
>> those hooks exclusively. If your needs outgrow what the admin provides, it
>> may be simpler to write your own views. The admin’s recommended use is as
>> an organization’s internal management tool. It’s not intended for building
>> your entire front end around."
>>
> What I have understood from using admin for years is that customizing
admin is really tough for new users, but for power users admin is a really
handy tool. I've written way complex user permission handling using admin
tool which could have given a hard time if written in normal django views.


> However several reviewers have made comments like "I worry that the
> description of the Admin sells it short. The Admin is actually brilliant
> kit and works as advertised." and "Downgrading Django's admin from
> "powerful and production ready" to "quick and dirty [old wording]" is very
> harsh... And I fear this will not only lower user's expectations, but also
> dev's carefulness!"
>
> I think part of the reason I raise this is that I'm getting weary of
> adding hook after hook for customizing every little thing. I worry we'll
> end up with an unmaintainable mess at some point. The latest proposal that
> has me thinking about this adds ModelAdmin.orderable_by and 
> ModelAdmin.get_orderable_by()
> for the use case of disabling sorting of a column in the change list [2].
> This topic also came up in the discussion of whether or not to add
> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done
> yet). There's also an open question about whether or not to add a view
> permission [4]. I don't want to discuss each of these decisions on this
> thread but rather the broader question of whether putting a lot of effort
> in this area is a direction we should pursue. I know there have been some
> proposals of "admin2" but realistically I think the admin has too many
> customizations points such that superseding it with something new and
> innovative won't be feasible from a backwards compatibility standpoint.
>
> Yes admin do provide customization for every little thing. IMHO, the power
of admin lies in this. A new admin might work but I fear power users won't
like it if it does not provide all those little customization like current
admin.

> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
> [1] https://github.com/django/django/pull/6104
> [2] https://github.com/django/django/pull/6107
> [3]
> https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
> [4]
> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion
>
> --
> 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/72ecc667-1dba-432e-a749-dca214fa77b5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAByqUgjZBxpzM5cXevF5a3Pcmj-Z5wQd_%3D8uwnvkfFqrMv%3D7nw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Riccardo Magliocchetti]

Hello,

Il 10/02/2016 00:25, Tim Graham ha scritto:

The introduction to the admin in the docs [0] reads:

"One of the most powerful parts of Django is the automatic admin interface.
It reads metadata in your model to provide a powerful and production-ready
interface that content producers can immediately use to start adding content
to the site."


I've proposed [1] changing it to:

"One of the most powerful parts of Django is the automatic admin interface.
It reads metadata from your models to provide a quick and rudimentary
interface where trusted users can manage content on your site.


s/rudimentary/basic/ maybe? As a non native english speaker rudimentary does not 
sound positive.




The admin has many hooks for customization but beware of trying to use those
hooks exclusively. If your needs outgrow what the admin provides, it may be
simpler to write your own views. The admin’s recommended use is as an
organization’s internal management tool. It’s not intended for building your
entire front end around."


To me that the intended use of the admin as internal management tools has been 
kinda obvious given it's accessible to user flagged as staff.


[snip]

I know there have been some proposals of "admin2" but realistically I think the
admin has too many customizations points such that superseding it with something
new and innovative won't be feasible from a backwards compatibility standpoint.


Wasn't the plan to revise these customizations points and thus probably breaking 
backwards compatibility anyway?



--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/56BAF8E2.3020706%40gmail.com.
For more options, visit https://groups.google.com/d/optout.