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.
