On 7/08/2017 4:43 PM, guettli wrote:
Hello this post is now four days old. I would like to hear from other people.


Something like:

 "I have no clue what you are talking about" or
 "I understand your concerns, but I have no clue, too" or
 "Thank you about talking about this, this raised my awareness"

I have a friend who invested heavily in a project (not Django) and went broke. The reason is he put some of the business logic in the database and some in the app. Because of that split, the project became unmaintainable. New developer hires didn't really understand.

I decided to do everything in the app. We retain flexibility to adjust the entire system provided you can see all the business logic in one place. Otherwise we would be relying on unseen magic. If performance becomes a problem and caching has not helped and schema redesign hasn't helped you can move logic to the database layer but only (sensibly) if the requirements have settled completely.

With migrations, Django is fabulous. It is possible you can migrate the IDML but we haven't reached that stage. Our project does depend on auth.permissions but also we run queries to display records based on licences which exist between users. I guess that is row-level "permissions". I investigated all the object-permissions apps with a view to implement one but our requirements would have needed complex code. Easier to do our own.

Cheers

Mike



would make me happy.

Thank you.

Am Donnerstag, 3. August 2017 10:07:53 UTC+2 schrieb guettli:

    First I asked a similar question on the postgresql-general list. The 
discussion[1] has settled there.

    Now I would love the hear what you think.


    I am thinking about rewriting an existing application which uses PostgreSQL 
via Django.

    Up to now the permission checks are done at the application level.

    Up to now queries like: "Show all items which the current user is allowed to 
modify" result in complicated SQL and
    this leads to slow queries.

    Up to now there is one db-user and the application does the filtering of 
rows to prevent application users to see
    items which they are not allowed to see.

    I guess most web applications work like this.

    I would like to reduce the "ifing and elsing" in my python code (less 
conditions, less bugs, more SQL, more performance)

    One important intention for me: I would like to avoid the redundancy. As 
soon as I want to query for
    "Show all items which the current user is allowed to modify" I need the 
permission checking in a SQL WHERE condition.

    If I implement this. Then my code which might look like this is redundant:

    {{{

    def has_perm(obj, user):
         if user.is_superuser:
             return True
         ...

    }}}


    Yes, I feel farewell pain. I love Python, but I guess I will use perm 
checking
    via SQL WHERE for new projects in the future. What do you think?   Regards,
        Thomas Güttler

    
[1]:https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
    
<https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de>

--
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 <mailto:django-users+unsubscr...@googlegroups.com>. To post to this group, send email to django-users@googlegroups.com <mailto: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/b2f0f560-9e83-4a90-9277-23c19f992c0b%40googlegroups.com <https://groups.google.com/d/msgid/django-users/b2f0f560-9e83-4a90-9277-23c19f992c0b%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
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/b3c424de-e0cc-9125-eef2-4321cf0d3ad0%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Reply via email to