Adding a one field to user model: trying not to create custom one)

[Ilya Kazakevich]

Hello,

I want to add just a one field to my model, and this field participates in user representation ( I use monkeypatch to change __str__).

Django manual tells me to create profile with one-to-one relation in this case. Well, it may work. But if I have <select> with 250 users, I face 250 "SELECT" queries to my db (N+1). I need to tell "UserManager" somehow to use "select_related". But how can I do that with out of new ugly monkeypatching?

Does there is an official (recommended) way to do that? If no, how  can I use one-to-one user profile if I have "list of users" webpage with out of N+1? How to add one field to user model not extending it?

I am really unhappy with idea of using custom user model.

Thanks.

[Carl Meyer]

Hello Ilya,

I am not aware of a good solution to this problem other than manually
adding the .select_related() to your query on the list-of-users page.

> I am really unhappy with idea of using custom user model.

Why?

If it's because this is an existing project and the prospect of
migrating your existing data to a custom user model is daunting, I
totally understand that. It's doable, but hard.

If this is a new project, I think that there is no good reason to avoid
a custom user model. Every new project should always use a custom user
model, even if to begin with it just inherits from AbstractUser and
doesn't change or add anything. This way in the future you have control
over your user model and can modify it as needed without monkeypatching.

Carl

[James Schneider]

The point of using a OneToOne relation to create a 'profile' is that the profile is meant to contain information that is only accessed on an individual basis (such as displaying a single users' address, etc.), and generally not involved on bulk queries as you describe.

If your __str__() method in your primary user model accesses an attribute via a foreign key lookup (ie OneToOne), then you'll get the behavior you are describing. You want the data that you'll need all or most of the time in the primary model to avoid that situation. In this case, I would suggest you look at the attribute you're referencing and move it directly into the primary user model.

I'm a little worried about what you mean by 'monkey patching'. Did you just override the __str__() methods on your primary model?

-James

--
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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5bdd87b6-9cc6-4490-8b85-d25ecfe8ed16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[x]

hello hello,

finally i was able to install a python instance on my shared-server.
it was also impossible to pip-install django. yeah.

but right then - so close already - i got a permission problem again.
i couldn't figure out exactly what django-admin.py wants to do/execute and why it's
not satisfied with my nice brand new local python 2.7.9 instance.. muhhuuu.

this is the ssh prompt:

> (uiserver):u74138225:~/django_build > django-admin.py startproject test --user-
> bash: /customers/homepages/45/d5012545412/htdocs/python27/bin/django-admin.py: Permission denied

for any suggestions how to domesticate django on this shared server i'd be very happy.

thanks and all the best
florian

[Tom Evans]

Web hosting platforms commonly (and should) have their htdocs on a
volume that is mounted with noexec, so that things cannot be executed.
Check with your hosting provider as to how they have things set up.

Incidentally, having your python code installed inside your htdocs is
a stunningly bad idea even if you can get it to work, as anyone who
can guess the path to a particular file would be able to read its
contents.

It might be worth contemplating a provider that is better suited to your needs.

Cheers

Tom

[Ilya Kazakevich]

Hello.

I am not aware of a good solution to this problem other than manually
adding the .select_related() to your query on the list-of-users page.

Oh :((

 

> I am really unhappy with idea of using custom user model.

Why?

If it's because this is an existing project and the prospect of
migrating your existing data to a custom user model is daunting, I
totally understand that. It's doable, but hard.

Yes, this project already deployed and has some data. Sure I can solve this, but I feel that changing user model will make my app less reusable. 

But I will probably stay with new model. There is something wrong with Django in this area. There should be some easy and elegant way to add one field to auth_user. I wonder why Django developers do not care about it.

 

[monoBOT]

2015-05-19 13:32 GMT+01:00 Tom Evans <teva...@googlemail.com>:

for any suggestions how to domesticate django on this shared server i'd be very happy.

​try 

​python /customers/homepages/45/d5012545412/htdocs/python27/bin/django-admin.py startapp myapp

--

monoBOT

Visite mi sitio(Visit my site): monobotsoft.es/blog/

[Ilya Kazakevich]

Hello.

On Tuesday, May 19, 2015 at 2:26:10 AM UTC+3, James Schneider wrote:

The point of using a OneToOne relation to create a 'profile' is that the profile is meant to contain information that is only accessed on an individual basis (such as displaying a single users' address, etc.), and generally not involved on bulk queries as you describe.

So, "profile" idea is useless here.

 

If your __str__() method in your primary user model accesses an attribute via a foreign key lookup (ie OneToOne), then you'll get the behavior you are describing. You want the data that you'll need all or most of the time in the primary model to avoid that situation. In this case, I would suggest you look at the attribute you're referencing and move it directly into the primary user model.

I'm a little worried about what you mean by 'monkey patching'. Did you just override the __str__() methods on your primary model?

Yes) I have app with hacky code in its AppConfig#ready() method.

This code does the following

user_model = get_user_model()

try:

    fields = settings.FIELDS

    user_model.__str__ = UserPresenter(fields, user_model.__str__).as_func()

    user_model._meta.ordering = fields

except AttributeError:

    pass  # No setting, do not touch user

 

UserPresenter class just checks for passed fields and returns string if they exist. 

So, I only need to add this app to INSTALLED_APPS and set FIELDS=["last_name", "first_name"] in my settings.py and it works.

I have the same for "get_absolute_url" method as well.

It is not very pythonic way to do something, but it works. 

[Carl Meyer]

On Tuesday, May 19, 2015 at 8:18:24 AM UTC-6, Ilya Kazakevich wrote:

> I am really unhappy with idea of using custom user model.

Why?

If it's because this is an existing project and the prospect of
migrating your existing data to a custom user model is daunting, I
totally understand that. It's doable, but hard.

Yes, this project already deployed and has some data. Sure I can solve this, but I feel that changing user model will make my app less reusable. 

I don't think "will make my app less reusable" is a valid reason to avoid a custom User model. A lot of thought went into the custom User model system to ensure that it preserves reusability. That's why things like `django.contrib.auth.get_user_model()` and friends exist.
 

But I will probably stay with new model. There is something wrong with Django in this area. There should be some easy and elegant way to add one field to auth_user. I wonder why Django developers do not care about it.

Django developers do care about the problem, and the preferred solution (after many years of discussion) is the custom User model. I believe that it's a better solution than introducing a hacky way to monkeypatch fields onto a built-in model. I think every Django project should use a custom User model.

Carl

[Andrew Farrell]

Hello Florian,

If you are having trouble installing python without root permissions, you should consider installing the miniconda distribution of python that is used in the scientific computing community. Assuming you are on a linux server, you can do this with

wget https://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh

chmod +x ./Miniconda-latest-Linux-x86_64.sh

./Miniconda-latest-Linux-x86_64.sh -b

conda update conda

conda create --name try_django django

source activate try_django

This will set you up with an isolated conda environment (similar to a virtualenv environment) where you can install packages without touching anyone else's packages. From there you can do

django-admin.py startproject test_project

cd test_project

python manage.py migrate

python manage.py runserver 0.0.0.0:8000

And to get yourself set up with the django dev server running on top of sqlite.

You can see the documentation for conda here.

--
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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/D96C8E64-18CA-4E2A-B9BD-D384AD563766%40zetteeh.net.

[x]

hey,

thanks for the quick responses!
before i go any further on installing i need to think about
tom evans advise:

> Incidentally, having your python code installed inside your htdocs is
> a stunningly bad idea even if you can get it to work, as anyone who
> can guess the path to a particular file would be able to read its
> contents.

but there is something i didn't understand: couldn't i go into the permissions
and do something like "chmod u-xwr <file>" if i wouldn't want one reading 'a specific' file?

i already found a host who's more python-friendly
then the one i'm currently stuck with ("1&1" in germany).

cheers
florian

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2By5TLYtn9e44mrY%3DrV_JXXXL2p0f0FuzEXcD2N3SQywG%2BWVcw%40mail.gmail.com.