Am Freitag, 11. August 2017 10:05:00 UTC+2 schrieb James Schneider: > > >> My concern is that this python code can't return a queryset with all > items where a given permission+user tuple match. > > > def has_perm(obj, user): > if user.is_superuser: > return True > > This means I need a SQL WHERE condition > > For example MyModel.objects.filter(Q(...)|Q(....)) > > I never wanted business logic in the database. Sorry, if you misunderstood me. > > has_perm() is not used for that purpose, so it isn't a fair comparison. > > If you want items specific to a permission gradient, you'll need to > determine the logic to emulate it yourself. In most cases, with a correct > model design, it isn't terribly difficult. > > For example, if user Joey can only see red widgets, then you would need to > specifically filter for red widgets in your view query set. The color (or > list of colors) may need to be pulled from a different table, causing a > second query. The ORM does have some advanced usages for filtering a model > based on values in an related model, in most cases using a JOIN to keep it > as a single cross-table query. If that's all you're trying to do, I doubt > any custom database procedure will be much faster than a good query set. > > I learned something during the last days. The question is not "Should permission checking be done at application level?" the question is "How to do the permission checking?"
Yes, I think like you. I guess using a database procedure or a django ORM filter() does not matter much. I guess it will have the same speed. > Do you have evidence of such queries being slow in the past? Profiling > them will lead you to the specific operations that may be slowing you down > and can likely be customized through more specific queries in a custom > authentication back end, or better direct querying within the views. > > Yes, here is the related issue: https://code.djangoproject.com/ticket/27260#comment:10 You can work-around this be using union() instead of sql-joins. I like python and in we did a lot of permission checking with code like this in the past "if ...: return True" - It needs some time to discover that this is a dead end if you want a queryset of all items sooner or later. don't get me wrong. I am not writing this because I complain. I write here because I want to learn more, and I write here because I want to spread the things I learned. This time, this topic is really ambivalent. Up to now I liked SQL but preferred python. Now I see that more and more source code moves to this simple set operations engine :-) With "moves to .." I mean this: My permission checks in the past: "if ...: return True" My permission checks in the future: SomeModel.objects.filter(Q(...)|Q(...)).exists() > Guardian is a good package, but frankly it is a polar opposite > implementation (all Python, use of GFK's incurring multiple queries, etc.) > from the one you are proposing. > > I want a get_objects_for_user(). That's my goal. Up to now I am unsure which strategy fits best. Regards, Thomas -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6381461b-ac40-41d2-bfe6-47fcb0acf64e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
