from:"carsten"

Am 04.04.19 um 16:23 schrieb Matthew Pava:
> If you need a default year in your template context, put it there.
> 
> def get_context_data(self, request, *args, **kwargs):
> context = super().get_context_data(request, *args, **kwargs)
> context['default_year'] = 2019
> return context
> 
> In your template, you could use this type of construct:
> {{ year or default_year }}
> 

No, the goal is to have a HTTP GET based form that the user can use to 
customize the view, and I'm looking for an elegant way to handle this with 
Django forms.

The key problem is that default values for form fields are not relevant when 
working with POST requests (where `initial` values are used in GET requests or 
request.POST data in POST request), but *are* relevant for HTTP GET 
(request.GET) based forms. As Django forms are tailored to work with `initial` 
and POST data, I've not yet found a really Django-elegant way to deal with this 
problem.

Best regards,
Carsten

-- 
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/fe1a5f18-7319-7358-00b4-2670e8111b08%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Using forms to handle request.GET data?

Am 04.04.19 um 16:24 schrieb Matthew Pava:
> And, since you really don't want constants littering your code, you probably 
> want something like this:
> context['default_year'] = timezone.now().year

Sure, thanks, but the year was only used to keep the example code minimal and 
the focus on how to handle a form that is based on request.GET data and has 
default values.   ;-)

Best regards,
Carsten

-- 
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/2374ce25-0a1e-8637-2608-af33f54ca9a9%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Using forms to handle request.GET data?

To elaborate on this further:

Searching the web for this yields numerous hits, e.g. 
https://stackoverflow.com/questions/16026479/django-forms-default-values-for-bound-forms
 mentions some ways to address this, but I've not come across a fully 
satisfactory solution.

Another approach might be this:


params = {'year': '2019'} # default values
params.update(request.GET)
year_form = JahrAuswahl(params)

# Can now use year_form normally, as intended:

if not year_form.is_valid():
# Pass year_form to the view to re-render the form with errors.
return render(..., {'year_form': year_form})

# year_form is valid, now use the year_form.cleaned_data values.
# If (unrelated) request.POST data turns out to be invalid,
# we may re-render year_form in this code path as well.
# ...


Thoughts?

Best regards,
Carsten

-- 
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/7cce7f43-e5e1-995a-a201-92905ba8f2bc%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Using forms to handle request.GET data?

Hello,

Am 03.04.19 um 21:28 schrieb Mohammad Etemaddar:
> Set default value:
> year = forms.ChoiceField(required=False, choices=[(j, j) for j in range(2018, 
> 2021)], default=2019)

Thanks for your reply, but unfortunately, `default` is a keyword for model 
fields only, not for form fields:
TypeError: __init__() got an unexpected keyword argument 'default'

Best regards,
Carsten

-- 
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/666f4ad3-cc32-ce9d-7a21-d860223ba2a9%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Using forms to handle request.GET data?

2019-04-02 Thread Carsten Fuchs

Dear Django group,

I would like to show users a form that they can use to customize the view, for 
example a ChoiceField from which the year of the report can be chosen. It seems 
straightforward to use a forms.Form to handle the request.GET data:


from django import forms

class JahrAuswahl(forms.Form):
year = forms.ChoiceField(required=False, choices=[(j, j) for j in 
range(2018, 2021)])

def clean_year(self):
y = self.cleaned_data['year']
if not y:
# Set a "default" value here.
y = 2019
print('Year:', y)
return y


However, the problem is with default values. Please consider this:


>>> year_form = JahrAuswahl({'year': 2018})   # Provide explicit data.
>>> print(year_form)
Year: 2018 # from JahrAuswahl.clean_year()
Year:
  2018# Just as expected!
  2019
  2020



>>> year_form = JahrAuswahl({})# Data is empty now, need default values!
>>> print(year_form)
Year: 2019 # JahrAuswahl.clean_year() provides a default value.
Year:
  2018
  2019   # BUT it doesn't make it back into 
year_form.data !
  2020



Well, the problem is that with {} (that is, request.GET == {}), we get default 
values in year_form.cleaned_data, but we cannot use year_form in the template 
context to render the form fields.
Some work-around might be to use the year_form.cleaned_data to initialize a new 
JahrAuswahl instance:


>>> year_form = JahrAuswahl(year_form.cleaned_data)   # HACK!?
>>> print(year_form)
Year: 2019
Year:
  2018
  2019# ok!
  2020



But this feels like a hack and really not like the proper way to do this.
How can I solve this problem in an elegant Django manner?

Best regards,
Carsten


-- 
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/07c57b13-a488-8a9d-5146-8aaa4b60fdd2%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: PLEASE HELP! Django documentation, Writing Your First App, Part 4

2019-02-03 Thread Carsten Fuchs

Well, you're adding choices to q = Question.objects.get(pk=1).
But is this also the question you call the view with?

I suggest you add a few more print statements below your existing

print(question)

For example:

print(question.pk)
print(question.choice_set.all())

# Or, a bit more verbose, for example:
for c in question.choice_set.all():
print(c.pk, c)

# Is the following a valid PK among the choices printed above?
print(request.POST['choice'])

Best regards,
Carsten


Am 2019-02-03 um 16:58 schrieb Atsunori Kaneshige:
> *_Here is the codes about choice_*
> 
> 
> In [27]: q = Question.objects.get(pk=1)
> 
> 
> In [28]: q.choice_set.all()
> 
> Out[28]: 
> 
> 
> In [29]: q.choice_set.create(choice_text='Not much',votes=0)
> 
> Out[29]: 
> 
> 
> In [30]: q.choice_set.create(choice_text='The sky',votes=0)
> 
> Out[30]: 
> 
> 
> In [31]: c = q.choice_set.create(choice_text='Just hacking again',votes=0)
> 
> 
> In [32]: c.question
> 
> Out[32]: 
> 
> 
> In [33]: q.choice_set.all()
> 
> Out[33]: , ,  Not much>]>
> 
> 
> In [34]: q.choice_set.count()
> 
> Out[34]: 3
> 
> 
> 
> choice exits, or correctly working?
> 
> Nori
> 
> On Sunday, February 3, 2019 at 10:55:48 AM UTC-5, Atsunori Kaneshige wrote:
> 
> Hi Carsten,
> 
> Sorry, are you talking about Writing Your First App, Part2? The page 
> below?
> https://docs.djangoproject.com/en/2.1/intro/tutorial02/ 
> <https://docs.djangoproject.com/en/2.1/intro/tutorial02/>
> 
> Yeah, when I tried this, there was something wrong.
> 
> *_I did that again. I copied and pasted my terminal below._*
> *_seems like migration was successful when I did before._*
> *_I am not sure what 'python sqlmigrate polls 001' is doing._*
> 
> 
> MacBook-Pro-3:mysite Koitaro$ python manage.py migrate
> 
> 
> /Applications/anaconda3/lib/python3.6/site-packages/psycopg2/__init__.py:144: 
> UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in 
> order to keep installing from binary please use "pip install psycopg2-binary" 
> instead. For details see: 
> <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi 
> <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>>.
> 
>   """)
> 
> Operations to perform:
> 
>   Apply all migrations: admin, auth, contenttypes, polls, sessions
> 
> Running migrations:
> 
>   No migrations to apply.
> 
> MacBook-Pro-3:mysite Koitaro$ python manage.py makemigrations polls
> 
> 
> /Applications/anaconda3/lib/python3.6/site-packages/psycopg2/__init__.py:144: 
> UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in 
> order to keep installing from binary please use "pip install psycopg2-binary" 
> instead. For details see: 
> <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi 
> <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>>.
> 
>   """)
> 
> No changes detected in app 'polls'
> 
> MacBook-Pro-3:mysite Koitaro$ python manage.py sqlmigrate polls 0001
> 
> 
> /Applications/anaconda3/lib/python3.6/site-packages/psycopg2/__init__.py:144: 
> UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in 
> order to keep installing from binary please use "pip install psycopg2-binary" 
> instead. For details see: 
> <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi 
> <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>>.
> 
>   """)
> 
> BEGIN;
> 
> --
> 
> -- Create model Choice
> 
> --
> 
> CREATE TABLE "polls_choice" ("id" serial NOT NULL PRIMARY KEY, 
> "choice_text" varchar(200) NOT NULL, "votes" integer NOT NULL);
> 
> --
> 
> -- Create model Question
> 
> --
> 
> CREATE TABLE "polls_question" ("id" serial NOT NULL PRIMARY KEY, 
> "question_text" varchar(200) NOT NULL, "pub_date" timestamp with time zone 
> NOT NULL);
> 
> --
> 
> -- Add field question to choice
> 
> --
> 
> ALTER TABLE "polls_choice" ADD COLUMN "question_id" integer NOT NULL;
> 
> CREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" 
> ("question_id");
> 
> ALTER TABLE "polls_choice" ADD CONSTRAINT 
> "polls_choice_question_id_c5b4b260_fk_polls_question_id&qu

Re: PLEASE HELP! Django documentation, Writing Your First App, Part 4

Hi Nori,

does the choice actually exist?
Can you find it if you query the choices using the ORM in `./manage.py shell`?

Best regards,
Carsten


Am 03.02.19 um 03:59 schrieb Atsunori Kaneshige:
> Hi Django users,
> 
> I started using Django recently.
> I am following the official Django tutorial.
> I am just at Writing Your First Django App, Part4, and I have been just 
> copying and pasting all codes.
> 
> But I have a problem in vote.
> I inserted print(question) and this is printed in detail.html
> also, question.id is also printed.
> 
> BUT, choice part doesn't seem working.
> 
> **
> def vote(request, question_id):
>     question = get_object_or_404(Question, pk=question_id)
>     print(question)
>     try:
>         selected_choice = question.choice_set.get(pk=request.POST['choice'])
>     except (KeyError, Choice.DoesNotExist) as e:
>         # Redisplay the question voting form.
>         print(e)
>         return render(request, 'polls/detail.html', {
>             'question': question,
>             'error_message': "You didn't select a choice.",
>         })
>     else:
>         selected_choice.votes += 1
>         selected_choice.save()
>         # Always return an HttpResponseRedirect after successfully dealing
>         # with POST data. This prevents data from being posted twice if a
>         # user hits the Back button.
>         return HttpResponseRedirect(reverse('polls:results', 
> args=(question.id,)))
> 
> **
> {{ question.question_text }}
> 
> {% if error_message %}{{ error_message }}{% endif %}
> 
> 
> {% csrf_token %}
> {% for choice in question.choice_set.all %}
>      value="{{ choice.id }}">
>     {{ choice.choice_text 
> }}
> {% endfor %}
> 
> 
> 
> 
> {{ question }}
> #printed 
>  
> {{ question.id }}
> #printed
> 
> _{{ question.choice_set.all }}_
> _# #what is this? empty? why?_
> 
> {{ question.question_text }}
> #printed
> 
> {{ question.question_text }}
> #printed
> 
> _{% for choice in question.choice_set.all %}_
> _    {{ choice.choice_text }}_
> _{% endfor %}_
> _#nothing printed!_
> 
> 
> Also when I click button 'vote', I only get error.
> *You didn't select a choice.*
> *
> *
> I am just copying and pasting so that I can understand Django, but I am 
> having hard time in this Part 4.
> 
> I really appreciate advice from anybody!
> 
> Nori
> 

-- 
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/713d3030-a03a-453a-a169-28cf980acd2a%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to access mysql db and apply changes using "python manage.py migrate"

Am 02.02.19 um 11:10 schrieb Emmanuel klutse:
> yes im talking about using "python manage.py migrate" command to create 
> tables in the db(djangoproject) i have already created in mysql server

`manage.py migrate` is trying to access your MySQL database, but the database 
denies the access to the user that is configured in your settings.
To fix this, you have to figure out why that is.

-- 
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/248b2ffc-85bf-fbd3-d0f8-f05e9bf34761%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to access mysql db and apply changes using "python manage.py migrate"

Am 02.02.19 um 10:33 schrieb Emmanuel klutse:
> [...] creat a db for me in mysql instead of sqlite and the error is talking 
> about authentication.
> these are the changes made in my djangoproject/settings file:
> DATABASES = {
>     'default': {
>     'ENGINE': 'django.db.backends.mysql',

You are asking for mysql.

-- 
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/bb96f20e-ceb6-d26c-e30d-1f755b35c574%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to access mysql db and apply changes using "python manage.py migrate"

Hi Emmanuel,

the error message is clear, isn't it?
(1045, "Access denied for user 'root'@'localhost' (using password: YES)")

Check your password. Use the mysql client to check.

Best regards,
Carsten


Am 02.02.19 um 10:07 schrieb Emmanuel klutse:
> hello team,
> Can someone help me with the problem below please.
> (py1) C:\djangoproject>python manage.py migrate
> Traceback (most recent call last):
>   File 
> "C:\Users\Success\Envs\py1\lib\site-packages\django\db\backends\base\base.py",
>  line 216, in ensure_connection
>     self.connect()
>   File 
> "C:\Users\Success\Envs\py1\lib\site-packages\django\db\backends\base\base.py",
>  line 194, in connect
>     self.connection = self.get_new_connection(conn_params)
>   File 
> "C:\Users\Success\Envs\py1\lib\site-packages\django\db\backends\mysql\base.py",
>  line 227, in get_new_connection
>     return Database.connect(**conn_params)
>   File "C:\Users\Success\Envs\py1\lib\site-packages\MySQLdb\__init__.py", 
> line 84, in Connect
>     return Connection(*args, **kwargs)
>   File "C:\Users\Success\Envs\py1\lib\site-packages\MySQLdb\connections.py", 
> line 164, in __init__
>     super(Connection, self).__init__(*args, **kwargs2)
> MySQLdb._exceptions.OperationalError: (1045, "Access denied for user 
> 'root'@'localhost' (using password: YES)")

-- 
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/e1ba1a10-e6d6-3d17-3531-34622305a595%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Migration question: why causes this change a non-empty migration?

2019-02-01 Thread Carsten Fuchs

Am 01.02.19 um 17:39 schrieb Tim Graham:
> I'm reluctant to continue investigation as you're using an old version of 
> Django and many bugs have been fixed since then. If you can reproduce a 
> problem with Django 2.2 alpha and a fresh database, feel free to create a 
> ticket if you can't find an existing ticket.

Ok, using Django 2.2a1 and a fresh database doesn't make a difference:
https://code.djangoproject.com/ticket/30152

Best regards,
Carsten

-- 
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/e3c1509a-9df8-af93-815d-09df9a31be58%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Migration question: why causes this change a non-empty migration?

2019-02-01 Thread Carsten Fuchs

Dear Django group,

using a model like this:

```
class Kostenstelle(models.Model):
id = models.AutoField(primary_key=True)
name = models.CharField(max_length=60, blank=True)
# ... omitted fields

class Meta:
db_table = 'kostenstelle'
```

I replaced the `id` line with

```
id = models.IntegerField(primary_key=True, help_text="...")
```

(This was a while ago, using Django 1.11.1.)
Running `manage.py makemigrations` created two migration files, numbers 0022 
and 0023:

```
# Migration 0022.
class Migration(migrations.Migration):

dependencies = [
('Lori', '0021_alter_Vortraege_jahr'),
]

operations = [
migrations.AlterField(
model_name='kostenstelle',
name='id',
field=models.IntegerField(primary_key=True, serialize=False),
),
]

# Migration 0023.
class Migration(migrations.Migration):

dependencies = [
('Lori', '0022_alter_Kostenstelle_id'),
]

operations = [
migrations.AlterField(
model_name='kostenstelle',
name='id',
field=models.IntegerField(help_text='...', primary_key=True, 
serialize=False),
),
]
```

This used to work properly with the Oracle DB backend, but today, using Django 
1.11.18 with MySQL backend, there are problems:
Running `./manage.py sqlmigrate Lori 0023` shows, as expected, an empty commit. 
With comments and newlines stripped: `BEGIN; COMMIT;`

I had expected `./manage.py sqlmigrate Lori 0022` to show an empty commit as 
well, as ttbomk, it doesn't imply any changes to the table schema. However, a 
lot of SQL statements were generated. Here the complete output, which also 
covers Foreign Keys that I omitted above:

```
(Zeiterfassung) carsten@black-steel-ubuntu:~/Zeiterfassung$ ./manage.py 
sqlmigrate Lori 0022_alter_Kostenstelle_id
BEGIN;
--
-- Alter field id on kostenstelle
--
ALTER TABLE `kostenstelle` DROP FOREIGN KEY 
`kostenstelle_parent_id_d0c73a18_fk`;
ALTER TABLE `Lori_oeffnungszeiten` DROP FOREIGN KEY 
`Lori_oeffnungszeiten_kst_id_54e15381_fk`;
ALTER TABLE `Lori_vertragsverlauf` DROP FOREIGN KEY 
`Lori_vertragsverlauf_kostenstelle_id_59f33815_fk`;
ALTER TABLE `Lori_userkstzuordnung` DROP FOREIGN KEY 
`Lori_userkstzuordnung_kostenstelle_id_ac2cc3c0_fk`;
ALTER TABLE `Lori_pekosollstd` DROP FOREIGN KEY 
`Lori_pekosollstd_kst_id_6b0156f7_fk`;
ALTER TABLE `kostenstelle` MODIFY `id` integer NOT NULL;
ALTER TABLE `kostenstelle` MODIFY `parent_id` integer NULL;
ALTER TABLE `Lori_oeffnungszeiten` MODIFY `kst_id` integer NOT NULL;
ALTER TABLE `Lori_vertragsverlauf` MODIFY `kostenstelle_id` integer NULL;
ALTER TABLE `Lori_userkstzuordnung` MODIFY `kostenstelle_id` integer NOT NULL;
ALTER TABLE `Lori_pekosollstd` MODIFY `kst_id` integer NOT NULL;
ALTER TABLE `kostenstelle` ADD CONSTRAINT `kostenstelle_parent_id_d0c73a18_fk` 
FOREIGN KEY (`parent_id`) REFERENCES `kostenstelle` (`id`);
ALTER TABLE `Lori_oeffnungszeiten` ADD CONSTRAINT 
`Lori_oeffnungszeiten_kst_id_54e15381_fk` FOREIGN KEY (`kst_id`) REFERENCES 
`kostenstelle` (`id`);
ALTER TABLE `Lori_vertragsverlauf` ADD CONSTRAINT 
`Lori_vertragsverlauf_kostenstelle_id_59f33815_fk` FOREIGN KEY 
(`kostenstelle_id`) REFERENCES `kostenstelle` (`id`);
ALTER TABLE `Lori_userkstzuordnung` ADD CONSTRAINT 
`Lori_userkstzuordnung_kostenstelle_id_ac2cc3c0_fk` FOREIGN KEY 
(`kostenstelle_id`) REFERENCES `kostenstelle` (`id`);
ALTER TABLE `Lori_pekosollstd` ADD CONSTRAINT 
`Lori_pekosollstd_kst_id_6b0156f7_fk` FOREIGN KEY (`kst_id`) REFERENCES 
`kostenstelle` (`id`);
COMMIT;
```

My main question is:
Why is this migration not empty, and is it safe to leave it out?


I'm asking this because I have trouble with applying this migration. 
Apparently, not all of the previously established foreign keys are dropped with 
the upper statements and recreated with the lower statements. Error message of 
`manage.py migrate`:
_mysql_exceptions.OperationalError: (1833, "Cannot change column 'id': used 
in a foreign key constraint 
'Lori_kalendereintrag_kostenstelle_id_edc2995b_fk_kostenste' of table 
'LoriDB.Lori_kalendereintrag_kstellen'")
but this constraint is not mentioned above.

Can anyone help me please?

Best regards,
Carsten

-- 
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/c91f5d42-6704-875e-842a-7188d804a44a%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Questions about MySQL notes in Django docs

2019-01-26 Thread Carsten Fuchs

Hi Jason,

Am 24.01.19 um 14:47 schrieb Jason:
> It doesn't look like the fixes were backported to 1.11, after looking in the 
> django 1.11 release notes.
> As Tim said, 
>> Based on the commits there, it looks like Django 2.0.7 and above 
>> received the fixes

Yes, that's part of my problem.

My project is already at Python 3.6 and normally I would now work through 
Django versions 2.0, 2.1 and soon 2.2, upgrading and testing at each iteration.

Unfortunately, Django 2.0 does no longer support Oracle 11 while Django 1.11 
doesn't have the MySQL fixes referenced by Tim.

That means that I'd be forced to switch from Django 1.11 to Django 2.0 and from 
Oracle 11 to MySQL 8 simultaneously – and that is more risk that I can bear. 
(Being able to follow Django's point releases at a reasonable pace is my main 
personal motivation for switching the database. Being stuck is really 
frustrating.)

Thus, the first step that I have to take is to switch the database to MySQL 8 
at Django 1.11.
Thus my question: ticket #29451 doesn't seem to affect my use case, but is 
there anything else that I should be aware of when using MySQL 8 at Django 1.11?

For example, web search leads to 
https://stackoverflow.com/questions/49949480/test-django-with-mysql-8-0-datetime-incompatible
However, I'm not experienced enough with MySQL 8 to draw the proper 
conclusions: Will Django 1.11 work anyways with the latest connector? 
https://bugs.mysql.com/bug.php?id=90541 suggests a work-around (for Django 
2.0), but does the datetime problem affect the recommended "mysqlclient" 
connector as well?

Which brings me back to my other questions:

b) Why is the "mysqlclient" client the recommended choice? --- quite the 
opposite is suggested at https://dev.mysql.com/doc/connector-python/en/

c) Regarding utf8, utf8mb3 and utf8mb4 there is conflicting information as well 
(https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html), but I can 
figure that out on my own.

Best regards,
Carsten

-- 
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/9fc409a5-814d-25df-9b74-a7418d75baea%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Questions about MySQL notes in Django docs

2019-01-24 Thread Carsten Fuchs

Hi Michael,

Am 23.01.19 um 13:56 schrieb Michal Petrucha:
>> d) Why is isolation level "read committed" preferred over "repeatable read"?
>> The text says "Data loss is possible with repeatable read.", but how can
>> "repeatable read" have data loss that "read committed" has not?
> 
> I can't answer the rest of your questions, but here's a discussion
> that might shed some light on this for you (along with the tickets
> linked from that thread):
> https://groups.google.com/d/msgid/django-developers/1c8af1c8-23dd-4c79-85ce-9486290ae73f%40googlegroups.com

Wow, that's very informative!
Thank you!

Best regards,
Carsten

-- 
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/bc0fea44-15ae-2b25-be47-0a66f9983cde%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Questions about MySQL notes in Django docs

2019-01-23 Thread Carsten Fuchs

Hi Tim,

thanks for your reply!

I'm sorry if I left the impression that I had not spent any time with research 
before posting my question!

Unfortunately and mistakenly, I was referring to the 2.1 docs when I am in fact 
still using Django 1.11:
My problem is that I still (have to) use an Oracle 11 database, which in turn 
gets me stuck with Django 1.11 LTS – this is one of the reasons for our planned 
switch to MySQL (unfortunately I was not able to persuade the team to use 
PostgreSQL instead).

Therefore, I have to switch from Oracle 11 to MySQL at Django 1.11.

Thus my question: With #29451 referring to Django 2.0, does the MySQL support 
in Django 1.11 cover MySQL 8, so that I can from there upgrade to newer Django 
versions?

Sorry again for having not made that clear in my initial message!

Best regards,
Carsten



Am 23.01.19 um 16:37 schrieb Tim Graham:
> Yes, Django supports MySQL 8. If you google "django mysql 8" the second 
> result is https://code.djangoproject.com/ticket/29451. Based on the commits 
> there, it looks like Django 2.0.7 and above received the fixes.
> 
> On Wednesday, January 23, 2019 at 5:10:18 AM UTC-5, Carsten Fuchs wrote:
> 
> Dear Django group,
> 
> can you please help me with some questions about
> https://docs.djangoproject.com/en/2.1/ref/databases/#mysql-notes 
> <https://docs.djangoproject.com/en/2.1/ref/databases/#mysql-notes> ?
> (I've been using Django with an Oracle database for years, but I'm new
> to MySQL.)
> 
> a) Does "Django supports MySQL 5.6 and higher." cover MySQL 8? (I'm not
> sure about the status of some tickets and PRs.)
> 
> b) Why is the "mysqlclient" client the recommended choice?
> 
> c) Using MySQL 8 and considering
> https://code.djangoproject.com/ticket/18392 
> <https://code.djangoproject.com/ticket/18392>, should we set utf8 or
> utf8mb4 as the character set?
> https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html 
> <https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html>
> indicates that utf8 is an alias to the deprecated utf8mb3 even with MySQL 
> 8.
> 
> d) Why is isolation level "read committed" preferred over "repeatable
> read"? The text says "Data loss is possible with repeatable read.", but
> how can "repeatable read" have data loss that "read committed" has not?
> 
> Thank you!
> 
> Best regards,
> Carsten


-- 
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/db2f7a92-9d28-97da-7d26-8a8de71a7213%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Questions about MySQL notes in Django docs

2019-01-23 Thread Carsten Fuchs


Dear Django group,

can you please help me with some questions about 
https://docs.djangoproject.com/en/2.1/ref/databases/#mysql-notes ?
(I've been using Django with an Oracle database for years, but I'm new 
to MySQL.)


a) Does "Django supports MySQL 5.6 and higher." cover MySQL 8? (I'm not 
sure about the status of some tickets and PRs.)


b) Why is the "mysqlclient" client the recommended choice?

c) Using MySQL 8 and considering 
https://code.djangoproject.com/ticket/18392, should we set utf8 or 
utf8mb4 as the character set? 
https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html 
indicates that utf8 is an alias to the deprecated utf8mb3 even with MySQL 8.


d) Why is isolation level "read committed" preferred over "repeatable 
read"? The text says "Data loss is possible with repeatable read.", but 
how can "repeatable read" have data loss that "read committed" has not?


Thank you!

Best regards,
Carsten

--
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/7d5c0f45-95eb-461b-ace5-3a823aacd2c7%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: best way to generate PDFs in django - handling concurrency

2018-12-27 Thread Carsten Fuchs

Hello,

in my project, using ReportLab exactly as documented works very well.

Best regards,
Carsten


Am 28.12.18 um 00:05 schrieb Danny Blaker:
> we're building an app for the council where users fill in a form, then we 
> generate a PDF (containing a page of text), and users get a download link on 
> the homepage. 
> we expect many users to submit forms concurrently.
> 
> I see 2 approaches:
> 
> 1. Generate in the view as per documentation : 
> https://docs.djangoproject.com/en/2.1/howto/outputting-pdf/
> 2. Use a seperate script to generate PDF and use django api 
> https://www.django-rest-framework.org/api-guide/parsers/#fileuploadparser
> 
> However, to handle concurrency we'll also need a broker - like rabbitMQ + 
> Celery
> 
> Is there a "best practice" way to approach this, or has anyone had experience 
> with generating PDFs in django and can recommend an approach?
> 
> Thanks!!
> 
> resources:
> 
> https://realpython.com/asynchronous-tasks-with-django-and-celery/
> https://simpleisbetterthancomplex.com/tutorial/2017/08/20/how-to-use-celery-with-django.html#why-should-i-use-celery
> 
> 
> -- 
> 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/9f06d9aa-7d89-4700-8cd0-9ae3343b3128%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-users/9f06d9aa-7d89-4700-8cd0-9ae3343b3128%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

-- 
Dipl.-Inf. Carsten Fuchs
Industriegebiet 3 ℅ Rofu
55768 Hoppstädten-Weiersbach
https://www.cafu.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.
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/33e14819-293d-8f54-9395-c5699aa29f7c%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: How to hide the password of postgresql in settings.py

2018-11-30 Thread Carsten Fuchs


Am 30.11.18 um 18:50 schrieb Sandip Nath:
I am a newbie to Django. Using Postgresql for CRUD operations. Although its 
working but I need to write the password of my Postgresql server in the 
settings.py. How can I hide that without hampering the operation?




In your settings.py, you could write something like:


from my_site import localconfig

DEBUG = localconfig.DEBUG
SECRET_KEY = localconfig.SECRET_KEY

# Rest of normal settings.py file
# ...


and in a minmal my_site/localconfig.py file:


DEBUG = True
SECRET_KEY = '...'


For completeness, be aware that some people consider local config files an anti 
pattern. Personally, I've never found the arguments convincing, but use at your 
own discretion.


Best regards,
Carsten

--
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/ddc528e3-12c1-6ba4-0f5b-1be7dad54acd%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: difference between class based view and function based view

2018-11-22 Thread Carsten Fuchs


Hi Andrew,

many thanks for your clear and detailed explanation!

Having used Django for several years, FVs are still my favorite approach 
over CBVs and GCBVs. In the past, I made several starts with CBVs, but 
never found or understood why CBVs and GCBVs seem to be in many people's 
center of attention.


FVs are not only the most simple of the three, but they also have the 
virtue of emphasizing the basic generic HTML web functionality and the 
way how forms work: The three logical paths that form processing can 
take are clearly shown in e.g. this (modified) example from 
https://django-book.readthedocs.io/en/latest/chapter07.html


def contact(request):
if request.method == 'POST':
form = ContactForm(request.POST)
if form.is_valid():
# success, now use form.cleaned_data
return HttpResponseRedirect('/contact/thanks/')
else:
form = ContactForm()

# We get here both for GET requests and POST requests
# with invalid forms.
return render(request, 'contact_form.html', {'form': form})

When I was new to Django (and in fact new to serious web development), 
understanding this concept, as step by step explained in the above 
mentioned chapter, was one of the key insights for me.


CBV and GCBV obscure this imho fundamental concept. Personally, I've 
never found the CBV's help with DRY outweigh the clarity of FVs. With 
all the attention and efforts that are spent on making getting started 
with Django easier for beginners, I was really surprised when even the 
official Django tutorials were changed from FVs to CBVs.


I write this email to thank you for your explanation, but also to add 
the above thoughts, which I have long been pondering but never found a 
place to write down.  ;-)


Best regards,
Carsten


Am 21.11.18 um 21:39 schrieb Andrew Pinkham:

Django developers talk about three kinds of views:

- function views (FV)
- class-based views (CBV)
- generic class-based views (GCBV)

People do not make always make the difference between CBV and GCBV, which is unfortunate, 
as they serve different purposes (naming things is hard). When Andréas states earlier in 
this thread that "(CBV) use a lot of defaults for populating your templates, forms 
and views" that is not 100% precise. He means GCBV---which provide default (generic) 
behavior---not CBV.

Let's break it down. Below is an example of a FV.

 from django.http import HttpResponse
 from django.views.decorators.http import (
 require_http_methods
 )

 # below is equivalent to require_safe decorator
 @require_http_methods(["GET", "HEAD"])
 def hello_world(request):
 """Demonstrate HTTP Request/Response"""
 return HttpResponse("Hello World")

Below is an example of an equivalent CBV.
  
 from django.http import HttpResponse

 from django.views import View
  
class HelloWorld(View):

  """Demonstrate HTTP Request/Response"""

 def get(self, request):
 """Handle GET HTTP method"""
 return HttpResponse("Hello World")

Formally, a CBV is any class that inherits from View. The only difference 
between the two views above is that the View class being inherited will give 
you automatic handling of HTTP OPTIONS.

Stated otherwise: FV and CBV are *equivalent* with the exception of automatic 
OPTIONS handling in CBV.

GCBV are simply CBV that have been given behavior. For example, instead of 
programming a view that shows a template with model data, you can instead 
inherit a DetailView, and customize it by setting class variables and by 
overriding methods. For more about that, I recommend looking at 
https://ccbv.co.uk .

So, when should you use a FV, CBV, or GCBV?

If you are building a view that a GCBV provides behavior for, save yourself 
time and use it! It's easy to add or slightly modify GCBV behavior, but 
difficult to remove behavior. The moment you're thinking about removing 
something a GCBV does, stick to a function or CBV.

So then, for choosing between FV or CBV: Do you need to handle multiple HTTP 
methods? Is there shared behavior between how the resource is handled by those 
HTTP methods? If yes, a CBV can help organize that logic and avoid duplicate 
code.

However, if you have a simple view (typically only one or two HTTP methods must 
be handled), then a FV will serve you fine (remember the view decorators!).

If you're not sure, start with a FV, and then switch to a CBV or GCBV if 
appropriate (as complexity goes up or when you realize you can use a GCBV).

Hope that helps,
Andrew
https://jambonsw.com
https://django-unleashed.com



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

Template filter {{ value|date:"M" }} in Python

2018-11-06 Thread Carsten Fuchs


Hello,

complementing template filters, sometimes it is necessary to format dates also 
in Python code, that is, achieve the equivalent to


{{ value|date:"M" }}

For this, I'm using

from django.utils import dateformat
dateformat.format(value, "M")

(This works in Django views and in test cases, but not in `./manage.py shell`.)

As `dateformat.format()` is not covered in 
https://docs.djangoproject.com/en/2.1/ref/utils/, but still very useful e.g. in 
tests, my question is if this is the correct way to achieve in Python what the 
`date` template filter does? Are there alternatives? (`strftime()` does not 
provide translated months names etc., and so isn't).


Best regards,
Carsten

--
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/cb938e74-d2e3-e4cf-13fa-580befd8f49c%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Prepopulate blog in b.entry_set.all()[i].blog ?

2018-10-20 Thread Carsten Fuchs


Can anyone help please?

Am 2018-10-11 um 16:58 schrieb Carsten Fuchs:

Dear Django group,

with Django 1.11.15, using the example models Blog and Entry at 
<https://docs.djangoproject.com/en/2.1/topics/db/queries/#related-objects> 
for reference, I have code like this:


     b = Blog.objects.get(name="...")
     for e in b.entry_set.all():
     print(e.blog)

Obviously, e.blog == b, but I found that for each e, the access to 
e.blog causes a subquery to fetch the blog object.


While I understand the concepts of select_related() and 
prefetch_related(), I was surprised that the e.blog attributes are not 
prepopulated with b. Why is that and what is the proper way to fix the 
problem?


Best regards,
Carsten



--
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/80c901cb-33c3-8ba8-a359-393cf00ca53d%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Prepopulate blog in b.entry_set.all()[i].blog ?

2018-10-11 Thread Carsten Fuchs


Dear Django group,

with Django 1.11.15, using the example models Blog and Entry at 
<https://docs.djangoproject.com/en/2.1/topics/db/queries/#related-objects> for 
reference, I have code like this:


b = Blog.objects.get(name="...")
for e in b.entry_set.all():
print(e.blog)

Obviously, e.blog == b, but I found that for each e, the access to e.blog causes 
a subquery to fetch the blog object.


While I understand the concepts of select_related() and prefetch_related(), I 
was surprised that the e.blog attributes are not prepopulated with b. Why is 
that and what is the proper way to fix the problem?


Best regards,
Carsten

--
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/74c03b14-bbcb-a33d-58bf-34835879ac7e%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with views PasswordChangeView vs. password_change

2017-07-14 Thread Carsten Fuchs


Am 13.07.2017 um 22:44 schrieb Tim Graham:

The success_url of PasswordChangeView (actually the behavior comes from the
inherited FormView) only accepts a URL, not a URL name. You can update to your
code like this:

from django.urls import reverse_lazy
...
success_url=reverse_lazy('lori:pwd_done')


That works!
Thank you very much!   :-)

Best regards,
Carsten

--
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/3ba5d272-cbf9-266e-4e8b-d9f8fcd8a6c6%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with views PasswordChangeView vs. password_change

2017-07-13 Thread Carsten Fuchs


Am 13.07.2017 um 16:56 schrieb Carsten Fuchs:

the   success_url='lori:pwd_done'   seems to be a problem


This seems to be the root also of the original problem (SuspiciousOperation…): 
If I insert a plain URL, e.g. success_url='/pwd_done/', then I can no longer 
reproduce the original problem either.


Best regards,
Carsten

--
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/a2656884-54a3-c465-e7e9-f1bf1720db5c%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Problem with views PasswordChangeView vs. password_change

2017-07-12 Thread Carsten Fuchs


Dear Django group,

using Django 1.11.3 with Python 2.7, please consider the following test:


def test_passwort_aendern(self):

u = User.objects.create_user("Test", "t...@example.com", "Passwort")
self.client.force_login(u)

response = self.client.post("/change_password/", {
"old_password": "Passwort",
"new_password1": "test",
"new_password2": "test",
}, follow=True)

self.assertContains(response, "Password successfully changed")


The test is successful if the URL maps to the (now unfortunately deprecated) 
function-based view:



from django.contrib.auth import views as auth_views

urlpatterns = [
# ...
url(r'^change_password/$', auth_views.password_change, 
{'post_change_redirect': 'lori:pwd_changed'}, name='change_password'),

]


If I use the class-based view in its place, the test fails:


urlpatterns = [
# ...
url(r'^change_password/$', 
auth_views.PasswordChangeView.as_view(success_url='lori:pwd_changed'), 
name='change_password'),

]


The test output is:

AssertionError: Couldn't retrieve content: Response code was 400 (expected 200)


When called in the browser, the result is an error page with:

SuspiciousOperation at /change_password/
The request's session was deleted before the request completed. The user may 
have logged out in a concurrent request, for example.


The given stack trace is below.


I have so far not been able to figure out the relationship between the session 
(which I guess the password change view expires intentionally?) and the error 
message…


Any ideas what may be causing this problem?

Best regards,
Carsten



Environment:


Request Method: POST
Request URL: http://localhost/lori/change_password/

Django Version: 1.11.3
Python Version: 2.7.3
Installed Applications:
('django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.staticfiles',
 'django.contrib.messages',
 'Lori',
 'PerfMon',
 'Spesen',
 'Urlaubsantraege')
Installed Middleware:
['django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'Lori.middleware.ggVerfallenMiddleware']



Traceback:

File 
"/home/carsten/.virtualenvs/Zeiterfassung/lib/python2.7/site-packages/django/core/handlers/exception.py"
 in inner
  41. response = get_response(request)

File 
"/home/carsten/.virtualenvs/Zeiterfassung/lib/python2.7/site-packages/django/utils/deprecation.py"
 in __call__
  142. response = self.process_response(request, response)

File 
"/home/carsten/.virtualenvs/Zeiterfassung/lib/python2.7/site-packages/django/contrib/sessions/middleware.py"
 in process_response
  61. "The request's session was deleted before the 
"

Exception Type: SuspiciousOperation at /change_password/
Exception Value: The request's session was deleted before the request 
completed. The user may have logged out in a concurrent request, for example.



--
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/c6cae2db-3436-4342-6d6f-387a9206064e%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Run model check with Django 1.11 as deployment check only?

2017-04-10 Thread Carsten Fuchs

Hi Matthew,

Am 10.04.2017 um 15:51 schrieb Matthew Pava:

I would argue that your code should be able to run successfully with an empty
database.
I would change your assignment of maxID to this:
maxID = cls.objects.aggregate(Max('id'))['id__max'] or 0

Normally, I would happily agree. However, in this case, the Status objects are
static and never supposed to change (without reloading the entire project).

Based on this assumption, all that I want is a constant `MAX_ID` that reflects
the largest possible ID of the existing Status objects, so that frequent access
to it does not each time inflict a database access.

Therefore, my older code just had a module global variable like this:

MAX_ID = Status.objects.aggregate(Max('id'))['id__max']

This is simple and "usually" works well, but note that it fails whenever an
empty database is initialized, that is, whenever the very first migration is run
(in which case the above global code is run even before the Status table
exists), which in turn happens when the project is deployed to a new site or
whenever the test database is populated.

In summary:

Code that is run at load time (such as the global `MAX_ID = ...` above) or close
to load time (such as the Django system checks) cannot access the database if
the database is only populated at a later time, as is the case with initial
migrations for new deployments or tests databases.

What I would like to check, though, is the production or development databases;
thus my question for marking the model check „for deployment only“.

Best regards,
Carsten

--
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/acc78088-9d44-97ee-915a-a9ad40974ff8%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Run model check with Django 1.11 as deployment check only?

2017-04-10 Thread Carsten Fuchs


Dear Django group,

with Django 1.10, I used a model check like this:


class Status(models.Model):
id = models.AutoField(primary_key=True)
MAX_ID = 38
text   = models.CharField(max_length=20, blank=True)

@classmethod
def check(cls, **kwargs):
errors = super(Status, cls).check(**kwargs)
maxID = cls.objects.aggregate(Max('id'))['id__max']

# The app sometimes computes histograms,
# so make sure that the Status.id values are as expected.
if cls.MAX_ID != maxID:
errors.append(checks.Warning(...))

return errors


This used to work well, considering that up to Django 1.10, this and other 
checks weren't run along with `manage.py test`.
Now that Django 1.11 runs checks also with tests, the above check obviously 
fails, because at the time the checks are run, the test database is still empty, 
yielding `maxID = None`.


Declaring the above check as “at deployment only” seems to be a good resolution, 
but is it possible to do that with a model (base-class based) check?


Best regards,
Carsten

--
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/03fdc69d-0ac8-b266-5533-d00301f9fdce%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: template {% url } tag syntax

2017-02-26 Thread Carsten Fuchs


Hi Richard,

Am 27.02.2017 um 04:01 schrieb Richard Belew:

{%url 'djggApp/guest'guest.guestId 'update'%}

but this generates a /NoReverseMatch/ error

/Reverse for 'djggApp/guest' with arguments '(1, u'update')' and keyword
arguments '{}' not found. 0 pattern(s) tried: []/



In the {% url %}, you use "update" as a parameter, so you should either 
write


{% url 'djggApp:updateGuest' guest.guestId %}

or, for example

url(r'^guest/(\d+)/(?P(update|something_else))$', 
login_required(views.GuestUpdate.as_view()), name='updateGuest'),


(there are alternative ways for this, e.g. using \w+)
Note that your view must deal with the new parameter.

And in the template

{% url 'djggApp:updateGuest' guest.guestId 'update' %}

Best regards,
Carsten

--
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/7621d668-8793-701f-9b16-7a5dc380dfe8%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Mocking date and time in LiveServerTestCase?

2017-01-30 Thread Carsten Fuchs


Hi Adam,

Am 25.01.2017 um 21:01 schrieb Adam Stein:

When I need to set the date to a known day for tests, I use forbiddenfruit
(https://github.com/clarete/forbiddenfruit).


Thanks for mentioning this, I didn't know it before!

However, I have not yet tried it, because I had hoped that there was a less 
intrusive method to achieve similar results and mostly because I still find it 
difficult to understand the ramifications of this approach with functional 
tests, that is, when LiveServerTestCase takes the server part (to be affected by 
forbiddenfruit) while the test case itself uses Selenium (and should, at least 
in theory, not be affected, e.g. for taking time measurements or log time stamps).


Alas, I guess that I'll just give up and write my tests in a work-around manner 
that circumvents details that depend on server time…


Best regards,
Carsten

--
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/4144b6e0-e377-a8e3-f9ab-ba6ad265acfb%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Mocking date and time in LiveServerTestCase?

2017-01-25 Thread Carsten Fuchs


Dear Django fellows,

I'm using LiveServerTestCase with Selenium. The application code run by 
LiveServerTestCase's live server works well and a view's call to date.today() 
returns the current date.


For the tests, however, it would be helpful if we could fix the time and date at 
which the test is supposedly run, making date.today() and similar functions 
return a predetermined value.


Can this be achieved?

Best regards,
Carsten

--
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/6ed32c80-cd29-1511-17bc-7cc79f485cc5%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.10.3 with Oracle database and --keepdb

2016-11-07 Thread Carsten Fuchs


Am 05.11.2016 um 15:55 schrieb Carsten Fuchs:

Am 2016-11-05 um 13:11 schrieb Mariusz Felisiak:

Yes. Please, make sure that your main oracle user has *ALTER USER*
permission.


I'll check (it may take until Monday or Tuesday though) and post an update here.


Indeed, after having added the ALTER USER permission everything works properly.

Many thanks to everyone!

Best regards,
Carsten

PS: It would be helpful if ALTER USER was added to the list of required 
permissions at https://docs.djangoproject.com/en/1.10/ref/databases/#oracle-notes




--
Carsten Fuchs Software
Industriegebiet 3, c/o Rofu
D-55768 Hoppstädten-Weiersbach
http://www.cafu.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.
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/743611e5-26fa-5671-9031-32656010c502%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.10.3 with Oracle database and --keepdb

2016-11-05 Thread Carsten Fuchs


Hi Mariusz,

Am 2016-11-05 um 13:11 schrieb Mariusz Felisiak:

Yes. Please, make sure that your main oracle user has *ALTER USER*
permission.


It is well possible that that is the culprit. I've set my database 
user's privileges as described at 
https://docs.djangoproject.com/en/1.10/ref/databases/#oracle-notes, so 
it's likely to miss `ALTER USER`.


I'll check (it may take until Monday or Tuesday though) and post an 
update here.


Best regards,
Carsten

--
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/14018aec-2ef8-52e2-42e1-ae4789e65247%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.10.3 with Oracle database and --keepdb

2016-11-05 Thread Carsten Fuchs


Hi Simon,

Am 05.11.2016 um 08:46 schrieb Simon Charette:

[0] https://code.djangoproject.com/ticket/27435#ticket


Thank you!

Best regards,
Carsten

--
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/4745b481-bf10-2fc1-5669-388aea4ab2d2%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Django 1.10.3 with Oracle database and --keepdb

2016-11-04 Thread Carsten Fuchs


Dear Django fellows,

using Django 1.10.3 with Oracle database, is running

  ./manage.py test --keepdb

supposed to work without having an explicit test password set?

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.oracle',
# ...
'TEST': {
# --keepdb no longer works for me without this:
'PASSWORD': 'password',
}
}
}

In other words, without setting an explicit (non-random) password, database 
errors are expected when starting the tests with --keepdb ?


Best regards,
Carsten

--
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/4742229b-49ae-0a1f-0757-e478239261fa%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Starting new project -- version 1.10

2016-08-23 Thread Carsten Fuchs


Am 23.08.2016 um 14:11 schrieb Michal Petrucha:

Finally, you need one Python package that serves as the “app” that
glues all the other packages together. This is the package (or app)
that contains the settings module, the root URL configuration, the
WSGI entry point, and often also static files, templates, views and
other stuff that only make sense in the context of the project itself,
and cannot reasonably be spun out into a separate package (that would
be things like the base template, or sometimes the landing page view).
This is what you referred to as the “project-under-the-project”.

The reason why this is inside a separate subdirectory is that you want
Python to be able to import it.


I cannot remember where is was stated, but iirc another reason for the 
“project-under-the-project” subdirectory was that it is considered not as app, 
but rather as “site”.


That is, if you deployed the same project in a different context (with different 
configuration), you would have another such “site” directory, e.g. 
clientmanagement/clientmanagement-internal/ or 
clientmanagement/test-other-webserver/ etc.


Best regards,
Carsten

--
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/be36f2a7-8f38-9c5d-3a90-b836aead863b%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: How to atomically create and lock an object?

2016-05-12 Thread Carsten Fuchs


Hi Simon,

that's awesome! This problem has been bothering me for a long time because I 
never quite understood how to get the locking / blocking and the transactions right.


Your's was a huge help, thank you very much for it!
  :-)

Best regards,
Carsten



Am 12.05.2016 um 17:10 schrieb Simon Charette:

Hi Carsten,

 > Why will the other thread block?
 > (Both threads may enter the "create" case, so the select_for_update() may not
 > yet be effective for the other thread?)

 > I looked into get_or_create()'s source code and the 
_create_object_from_params()
 > method that it calls. Is this due to the "second"
 > return self.get(**lookup), False
 > near its end?

Exactly. Only one thread will succeed in creating the object. The other one will
get an `IntegrityError` and try to `.get()` the existing object which is going
to use `select_for_update(nowait=False)`-- a blocking call.

 > Also, I understand the purpose of wrapping demonstrate_the_problem() in
 > atomic(), accounting for possibly unrelated exceptions in "long `some_value`
 > computation". But why does _create_object_from_params() wrap its single call 
to
 > `create()` in atomic(), too? Isn't create() inherently atomic?

The create() method is atomic but in order to recover from an integrity error
it could raise on conflictual data it must be wraped in a transaction
(if autocommit is on) or use a savepoint in your case because a transaction
is already started by the demonstrate_the_problem() atomic wrapper. Else the
connection is left in an unusable state by the integrity error.

Cheers,
Simon

Le jeudi 12 mai 2016 10:48:30 UTC-4, Carsten Fuchs a écrit :

Hi Simon,

many thanks for your reply!
Please see below for some follow-up questions.

Am 11.05.2016 um 16:04 schrieb Simon Charette:
 > Did you try using select_for_update() with get_or_create()[1] in an
 > atomic()[2] context?
 >
 > @transation.atomic
 > def demonstrate_the_problem():
 >  d = date.today()
 >  t = TestModel.objects.select_for_update().get_or_create(
 >  jahr=d.year, monat=d.month
 >  )
 >  # ... long `some_value` computation
 >  t.some_value = 123
 >  t.save(update_fields={'some_value'})
 >  return t
 >
 > Note that in this case if another thread tries to select_for_update() it 
is
 > going to block at the get_of_create() until the first thread's 
transaction
 > commits.

Why will the other thread block?
(Both threads may enter the "create" case, so the select_for_update() may 
not
yet be effective for the other thread?)

I looked into get_or_create()'s source code and the
_create_object_from_params()
method that it calls. Is this due to the "second"
 return self.get(**lookup), False
near its end?

Also, I understand the purpose of wrapping demonstrate_the_problem() in
atomic(), accounting for possibly unrelated exceptions in "long `some_value`
computation". But why does _create_object_from_params() wrap its single 
call to
`create()` in atomic(), too? Isn't create() inherently atomic?

Best regards,
Carsten




--
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/5734A9DA.1010100%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: How to atomically create and lock an object?

2016-05-12 Thread Carsten Fuchs


Hi Simon,

many thanks for your reply!
Please see below for some follow-up questions.

Am 11.05.2016 um 16:04 schrieb Simon Charette:

Did you try using select_for_update() with get_or_create()[1] in an
atomic()[2] context?

@transation.atomic
def demonstrate_the_problem():
 d = date.today()
 t = TestModel.objects.select_for_update().get_or_create(
 jahr=d.year, monat=d.month
 )
 # ... long `some_value` computation
 t.some_value = 123
 t.save(update_fields={'some_value'})
 return t

Note that in this case if another thread tries to select_for_update() it is
going to block at the get_of_create() until the first thread's transaction
commits.


Why will the other thread block?
(Both threads may enter the "create" case, so the select_for_update() may not 
yet be effective for the other thread?)


I looked into get_or_create()'s source code and the _create_object_from_params() 
method that it calls. Is this due to the "second"

return self.get(**lookup), False
near its end?

Also, I understand the purpose of wrapping demonstrate_the_problem() in 
atomic(), accounting for possibly unrelated exceptions in "long `some_value` 
computation". But why does _create_object_from_params() wrap its single call to 
`create()` in atomic(), too? Isn't create() inherently atomic?


Best regards,
Carsten

--
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/5734979A.7050608%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

How to atomically create and lock an object?

2016-05-11 Thread Carsten Fuchs


Dear Django group,

please consider this code:


from datetime import date
from django.db import models


class TestModel(models.Model):
jahr = models.SmallIntegerField()
monat = models.SmallIntegerField()
some_value = models.SmallIntegerField()

class Meta:
unique_together = ('jahr', 'monat')


def demonstrate_the_problem():
d = date.today()

try:
t = TestModel.objects.get(jahr=d.year, monat=d.month)
# t exists, no need to create or modify it.
return t.some_value
except TestModel.DoesNotExist:
# t did not yet exist, so we have to create it anew.
# Note that there is a "unique together" constraint in place
# that makes sure that the tuple (jahr, monat) only exists once.
# Thus we create a new instance, then lock it with
# select_for_update()  --  but this is still not atomic!
TestModel(jahr=d.year, monat=d.month).save()
t = TestModel.objects.get(
jahr=d.year, monat=d.month).select_for_update()

# A long computation, eventually setting fields in the new t,
# then saving it for the next call to this function.
t.some_value = 123
t.save()
return t.some_value


The problem is that another thread too may have created a TestModel with the 
same (jahr, monat) in the timespan between our "does not exist" and "lock", 
triggering a violation of the "unique" constraint.


Thus, the question is how we can make the sequence "does not exist – create anew 
– lock" atomic?


Any feedback would very much be appreciated!

Many thanks and best regards,
Carsten

--
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/5733370C.2050001%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: How to learn Django stepwise Effectively

2016-01-21 Thread Carsten Fuchs


Hi Andrew,

Am 20.01.2016 um 15:31 schrieb Andrew Pinkham:

There are many resources for learning Django (NB: this email assumes you’re not 
looking to learn Python).


Thank you very much for assembling this list, it's very much appreciated!
I knew many of these resources, but certainly not all.

When I was entirely new to Django, besides the Django Tutorial the old Django 
Book's chapter about forms was a huge help to me, starting at plain HTML and 
eventually arriving a full Django view. I was almost afraid that it's nice 
introduction would eventually get lost, especially for those who are newly 
learning this as I once was. So among other things, I was very happy to hear 
about http://masteringdjango.com/django-forms/   :-)


Best regards,
Carsten

--
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/56A0DBDC.3060901%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Django for Data Tables to group by when coloumn hidden

2015-12-10 Thread Carsten Fuchs


Hi Sid,

if with Data Tables you are in fact referring to http://datatables.net/, then you should 
put your questions with the folks over there. I guess what you want is possible with 
DataTables (I haven't checked), but be prepared for some customization with JavaScript 
being required.


If you want to solve the problem in pure Django (that is, with no JavaScript help on the 
client), I would probably create two different views, one for the table with and the 
other without the second column. The docs at 
https://docs.djangoproject.com/en/1.9/topics/db/aggregation/ explain very well the 
concepts that you need in order to build the table with the second column collapsed.


Best regards,
Carsten



Am 09.12.2015 um 16:07 schrieb Sid:

*Question:* I have a Data table displaying on django , but now I like to group 
by when
ever I will hide the column.


*column1 column2 column3*

AAACAD25

AAAUSD12

BBBCAD13

BBBUSD16

CCCCAD11

CCCUSD18


The above table will be displayed on web page using Django, now when ever I hide
*column2* It should group by and display like below table.


*column1* *column3*

AAA  37

BBB  29

CCC  39


when ever I unhide it again it should display same as first table again.

*can anyone tell me there is any possible way to do it.*


Thanks in advance.




--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5669B63A.3050301%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with appending slash at the end of the url

2015-12-07 Thread Carsten Fuchs


Hello,

Am 07.12.2015 um 13:37 schrieb Dongwon Kang:

I don't know even it's a problem, but anyway, I just updated django 1.8.7 to 
django 1.9
and found application isn't working.

I found out django wasn't redirecting not-slashed url. it returns 500 error if 
slash
hadn't been at the end of the url. but it works well if it's in Debug mode.


It is the CommonMiddleware that implements a redirect from "no-slash" to "slash/" URLs, 
see 
<https://docs.djangoproject.com/en/1.8/ref/middleware/#module-django.middleware.common> 
for details, so maybe some (other) middleware is involved that causes the trouble?


I'm mentioning this because I recently had a similar problem, where my own middleware 
caused problems when another middlewere (in this case, the CommonMiddleware) interfered, 
that is, replied to a request, which in turn was  unexpected for my custom middleware, 
causing it to fail.



but the most thing I suffer from is It works if a url is loaded in debug mode. 
for
example, resolving /iidx/test returns 500, but if /iidx/test was loaded 
successfully in
debug mode, then the url is called well even if it's release mode.


Maybe you can have an email sent to you if a 500 error occurs, and/or check the error 
logs of your webserver, so that you can see the stack trace to see where the error 
occurs. You'll need this information in order to fix the problem.


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5665CB55.5070208%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Locking / serializing access to one element in database

2015-11-05 Thread Carsten Fuchs


Hi Collin,

Am 05.11.2015 um 16:36 schrieb Collin Anderson:

If you're just updating one field, this _might_ work for you:


Why just one?



|
try:
TestMonthModel.objects.create(jahr=Jahr,monat=Monat)# create() uses 
force_insert.
exceptIntegrityError:
pass  # It already exists. No Problem.
# ... calculate some things.
TestMonthModel.objects.filter(jahr=Jahr,monat=Monat).update(value=new_value)
|


It's a nice idea, and I'll have to think more about it, but I guess that while this 
forces two parallel accesses to work with the same single instance, they can still both 
enter the calculation step, whose side effects may be hard to foresee in this context. 
Both will eventually also update the instance at the end, possibly with different 
results…  I'll have to think more about this.  ;-)


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/563BBF7A.50506%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: update_or_create() always creates (or recreates)

2015-11-05 Thread Carsten Fuchs


Hi Yunti,

Am 05.11.2015 um 18:19 schrieb Yunti:

I have tried to use the update_or_create() method assuming that it would 
either, create
a new entry in the db if it found none or update an existing one if it found 
one and had
differences to the defaults passed in  - or wouldn't update if there was no 
difference.


A note about the last statement: If a Supplier object has the same unique_id, and all 
other fields (in `defaults`) are the same as well, logically there is no difference 
between updating and not updating – the result is the same.



  However it just seemed to recreate entries each time even if there were no 
changes.


Have you checked? How?
In your create_or_update_if_diff() you seem to try to re-invent update_or_create(), but 
have you actually examined the results of the


supplier, created = Supplier.objects.update_or_create(...)

call?


I think the issue was that I wanted to:
1)  get an entry if all fields were the same,


update_or_create() updates an object with the given kwargs, the match is not made 
against *all* fields (i.e. for the match the fields in `defaults` are not accounted for).



2) or create a new entry if it didn't find an existing entry with the unique_id
3) or if there was an entry with the same unique_id, update that entry with 
remaining
fields.


update_or_create() should achieve this. It's hard to tell more without additional 
information, but 
https://docs.djangoproject.com/en/1.8/ref/models/querysets/#update-or-create explains 
the function well, including how it works. If you work through this in small steps, 
check examples and their (intermediate) results, you should be able to find what the 
original problem was.


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/563BB657.7050209%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: formset concurrency control

2015-10-29 Thread Carsten Fuchs


Hi all,

continuing my previous post, I've implemented most of the ideas mentioned in this thread 
now, and would like, for completeness and future reference, add some related findings 
and thoughts:


As mentioned in my previous post, reconstructing the formset's initial data (the 
queryset) in the POST request by the same parameters that were used to construct the 
queryset for the initial formset data in the GET request, in *addition* to the primary 
keys received in the POST request, turned out to work very well. That is, the code is 
roughly like this:


# Inits is made from the view's appropriate queryset.
Inits = ...

# In the case of the GET request:
formset = TestFormSet(initial=Inits)

# In the case of the POST request:
formset = TestFormSet(request.POST, initial=Inits)


This is how the initial data is useful in the POST request:

  - It is required for validation in order to be able to detect "high-level" kinds of 
concurrency related mismatches (number of instances changed, deleted instances, 
unexpected new or replaced instances).


  - We also need the same data for "low-level" concurrency control, e.g. checking a 
`VERSION` number as e.g. in [1] and [2].


  - As a side effect of the same validation steps, tampering with the POST data is 
detected as well.


  - The initial data (`Inits` above) is also a convenient place for storing arbitrary 
extra data, e.g. the actual model instances, that can be used for rendering additional 
information in the template.


  - In the case of successful formset validation, the readily available queryset 
instances can be used for storing and saving the submitted data.



I still use custom Forms for all this, not ModelForms, because:

  - As we need the model instances anyway and already got them via the queryset as 
described above, using a ModelForm(-set) that implicitly instantiates them all again 
would not be efficient.


  - I have a lot of cases where I have a field flagged as "required" in the model, but 
"not required" in the form. This helps with making entire forms optional in the formset 
(won't get saved if not filled out), but makes clear what is required when a model is 
eventually saved. This is especially helpful when forms are rendered for which not 
necessarily a model instance exists and is not necessarily created, as e.g. in my 
CalenderEntry example described in another post of this thread ([3]).


  - Foreign keys are problematic. Although a ModelForm covers a FK just as it covers 
the model's PK, if we wish to extend the concept of validating `VERSION` numbers (as 
above) also to the related models, the form must be augmented with an appropriate 
version number field for each FK. (I have not checked, but adding such extra fields is 
probably possible with ModelForms as well.)



Well, so far my findings. Although this seems to work well, I'd very much appreciate any 
further comments and thoughts.


Best regards,
Carsten


[1] https://github.com/saxix/django-concurrency
[2] https://github.com/gavinwahl/django-optimistic-lock
[3] https://groups.google.com/d/msg/django-users/R7wJBTlC8ZM/N3dNlMrGCwAJ


--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5632477F.4050107%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Locking / serializing access to one element in database

2015-10-28 Thread Carsten Fuchs


Hi Collin, hi all,

Am 27.10.2015 um 19:56 schrieb Collin Anderson:

Yes, an exception will be raised.


Thinking further about this, all we need is a method that gives us an exception if we 
accidentally create a second object when in fact only one is wanted. Your suggestion 
with manually dealing with the PKs and using .save(force_insert=True) is one method to 
achieve that, another one that works well for me is using an (application-specific)


unique_together = (year, month)

constraint, which achieves the desired result (guarantee uniqueness where required, 
raise an exception otherwise) without having to manually deal with PKs.


Alas, I wonder how to proceed to complete the solution. As I find it simpler to deal 
with the above mentioned unique_together rather than with coming up with a PK based 
solution, I refer to my original code from [1], which was:



try:
mm = TestMonthModel.objects.select_for_update().get(jahr=Jahr, 
monat=Monat)
except TestMonthModel.DoesNotExist:
mm = TestMonthModel(jahr=Jahr, monat=Monat)

# A *long* computation, eventually setting fields in mm and save:

mm.value = 123
mm.save()


Combining everything from this thread, this could be changed into this code 
(pseudo-code, not tested):



while True:
try:
mm = TestMonthModel.objects.select_for_update().get(jahr=Jahr, 
monat=Monat)
break   # Got what we wanted!
except TestMonthModel.DoesNotExist:
try:
# Create the expected but missing instance.
# No matter if the following succeeds normally or throws
# an Integrity error, thereafter just restart the loop.
TestMonthModel(jahr=Jahr, monat=Monat).save()
except IntegrityError:
pass

# A *long* computation, eventually setting fields in mm and save:

mm.value = 123
mm.save()


Afaics, this solves the problem, but it also feels quite awkward and I wonder if there 
is a more elegant solution.


Comments? Does this sound reasonable at all?

Best regards,
Carsten

[1] https://groups.google.com/forum/#!topic/django-users/SOX5Vjedy_s

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/563126B1.9090609%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Locking / serializing access to one element in database

2015-10-22 Thread Carsten Fuchs


Am 22.10.2015 um 01:16 schrieb Simon Charette:

I would suggest you use select_for_update()
<https://docs.djangoproject.com/en/1.8/ref/models/querysets/#select-for-update> 
in a
transaction.


This only covers the case where the object with the given ID already exists, 
doesn't it?

That is, if a new object is created in the except-clause, concurrent threads might 
create a new object each, whereas it would presumably be expected that new_text is 
(twice) added to a single common instance.


As I had the quasi exact same question a while ago (see 
https://groups.google.com/forum/#!topic/django-users/SOX5Vjedy_s) but never got a reply, 
I (too) am wondering how the new-object case in the except-clause could be handled?


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5628EAD4.9090602%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Reverse access model through a “double” ForeignKey

2015-10-14 Thread Carsten Fuchs


Am 14.10.2015 um 11:11 schrieb Gergely Polonkai:

This setup, though, doesn’t feel right, as it contains redundancy. Is there a 
way to
access the list of Values directly from Build without having this redundancy?


Well, you can filter your Value queryset by Build, see
https://docs.djangoproject.com/en/1.8/topics/db/queries/#lookups-that-span-relationships

Or, starting with a Build instance, you can work towards the Value instances, 
see
https://docs.djangoproject.com/en/1.8/topics/db/queries/#related-objects

Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/561E540F.6030202%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: If appears doesn't work in template, why?

2015-10-14 Thread Carsten Fuchs


Am 14.10.2015 um 13:36 schrieb Fellipe Henrique:

But, always enter in "else"... even the record was saved with "A"... I tried 
with 'A'
and "A", same "problem"...

Any ideas, what's going on?


Have you cross-checked? I.e., what is the output of {{ status }} ?

Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/561E5230.1010203%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: formset concurrency control

2015-10-09 Thread Carsten Fuchs


Hi Tim,

Am 08.10.2015 um 21:03 schrieb Tim Graham:

I think the problem is also described in 
https://code.djangoproject.com/ticket/15574.
Probably if we had a simple solution, that ticket wouldn't be open for 5 years. 
:-)


:-)

Yes, having read all of it, I too think that #15574 describes the same problem.

The more I think about it, reconstructing the queryset in the POST request by the same 
parameters that were used to construct the queryset for the initial formset data in the 
GET request, in *addition* to the primary keys in the POST request, seems like an 
increasingly good idea to me:


In formset validation, comparing the queryset objects with the PKs from the POST request 
should yield an exact match (validation successful).


If there is any mismatch, it is probably best to just tell the user that there was a 
problem (in some specific cases it might be possible to fix and/or communicate the 
mismatch, but not generally). He/she may lose some work (has to reload and fill in the 
entire form again), but that still seems a lot better to me than saving something that 
the user has not seen (or seen differently) and may come entirely surprising.


This approach looks reasonably simple and stable to me, and I'll definitively try it 
out. As a second but independent step, it should even be relatively easy to add 
fine-grained concurrency control to it as mentioned in my first post.


As always, any additional comments or thoughts would very much be appreciated!

Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5617D9F4.6070901%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: formset concurrency control

2015-10-08 Thread Carsten Fuchs


Hi Daniel,

Am 08.10.2015 um 18:48 schrieb Daniel Roseman:

Can you explain further why you think the pk is not sufficient? Ordering by 
name, or
adding and removing entities, does not change the pk of other entities; indeed 
that's
the whole point of a pk. What exactly are you concerned about?


Please consider this example:


from django.db import models

class Calendar(models.Model):
pass

class CalendarEntry(models.Model):
cal  = models.ForeignKey(Calendar)
ref_date = models.DateField()
entry= models.CharField(max_length=40, blank=True)

class Meta:
unique_together = ('cal', 'ref_date')


We would like to present the user a formset (for a specific Calendar instance) where 
e.g. October 2015 is shown in tabular form: each day of the month is shown with a static 
date string, and next to it is an input field for the "entry" text.


The key issue is of course that for days that don't have an entry, no CalenderEntry 
instance exists.


Now, the GET request is relatively easily dealt with (as explained in the other thread 
https://groups.google.com/d/msg/django-users/jA2KUdp1MUE/pceQZPYHBgAJ, I intentionally 
use a plain Form, not a ModelForm, both for better understanding and, to me, unclear 
performance implications):



from django import forms

class CalendarEntryForm(forms.Form):
CalEntr_id = forms.IntegerField(required=False, 
widget=forms.HiddenInput())
ref_date   = forms.DateField(widget=forms.HiddenInput())
entry  = forms.CharField(required=False, max_length=40)


The form's ref_date member is needed for all cases where a CalenderEntry instance does 
not (yet) exist. In the view's part where the GET request is processed, the formset 
would be constructed e.g. like this:



# Example is specific to October:
from datetime import date
october_inits = [{"ref_date": date(2015, 10, i + 1)} for i in range(31)]

for ce in CalendarEntry.objects.filter(cal=MyCal, ref_date__year=2015, 
ref_date__month=10):

init = october_inits[ce.ref_date.day - 1]

init["CalEntr_id"] = ce.id
init["entry"] = ce.entry

CalenderEntryFormSet = formset_factory(CalenderEntryForm)
formset = CalendarEntryFormSet(initial=october_inits)


So far, all is good, but problems start to occur when we get the form back in the POST 
request. When comparing the data from the POST request to those of a newly created 
october_inits list, CalenderEntry instances mentioned in the POST request may have been 
deleted in the meanwhile or been replaced by an entirely different CalenderEntry 
instance. On other days on which the POST data assumed that a CalenderEntry did not yet 
exist, an instance may be existing now, etc.


Obviously, the number of days in October is fixed at 31, but if this was something else, 
such as a list of persons to which CalenderEntry objects are attached, more or fewer 
persons could exist when the POST request is processed.


While some of these cases can be detected with the pk alone, and others possibly with 
the help of the unique-constraint and the related exception, I'm not sure if this can 
really cover all the cases.


For example, if someone tampered with the POST request and submitted a wrong pk – from 
the pk and the related instance alone we can probably not learn that there is a problem, 
and what it is.


Well, I readily admit that this hits the limits of my skills and thoroughly confuses me, 
thus my question how all this is best or typically dealt with.  :-)


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5616CD6D.7050605%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

formset concurrency control

2015-10-08 Thread Carsten Fuchs

Dear Django fellows,

as far as I understand this, there seem to be two kinds of concurrency control:

- the one that occurs between request and save, as addressed by e.g. [1] and
[2],
- the one that occurs between GET request and POST request, especially with
formsets.

I'm currently trying to understand the latter (apparently even the Django Admin suffers
from this problem, https://code.djangoproject.com/ticket/11313).

What I am wondering is, when Django formsets are used, what is the canonical way to
address this problem?

It seems that each form in the formset must be given the PK of the object that it is
related to, but I don't think that that is sufficient:
If the formset in the GET request is constructed from a queryset of e.g. a list of
persons, ordered alphabetically by name, at the time of the POST request persons may
have been added or deleted, causing discrepancies.
Thus, each form in the formset must be given the PK, but we must *also* construct the
original queryset in the POST request, then compare these two.

Right?

Best regards,
Carsten

PS: This is (ttbomk) also very much related to protecting against erroneous or tampered
POST requests, e.g. added or removed forms in the formset – the solution seems to be the
same. I've described this in more detail at
https://groups.google.com/d/msg/django-users/jA2KUdp1MUE/pceQZPYHBgAJ – any help would
be very much appreciated.

[1] https://github.com/saxix/django-concurrency
[2] https://github.com/gavinwahl/django-optimistic-lock

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/56167540.8050907%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Formset questions: data vs. initial values

2015-10-08 Thread Carsten Fuchs


Hi Shawn,

many thanks for your reply.

Am 07.10.2015 um 15:54 schrieb Shawn Milochik:

You /can/ use ModelForms for this. You don't need an active instance.


Thanks, I'll definitively check this out!

However, using a ModelForm wastes performance when the POST request is processed, 
doesn't it?


This is because both in the GET and the POST request, I have to construct the queryset 
in order to have the instances that the formset is about:


  - in the GET request, the queryset is needed in order to construct the 
formset,
  - in the POST request, the queryset is needed for comparison, in order to detect 
unexpected changes (e.g. a calender entry that didn't exist at the time of the GET 
request suddenly exists at the time of the POST request, or vice versa, etc.)


If I used ModelForms in such a formset, all objects were instantiated both in the 
original queryset as well as in all the ModelForms constructed from request.POST, 
essentially duplicating the database queries, wouldn't they?



You can have multiple forms using "prefix," which could just be the date as a 
string.


Why would I need "prefix" if a formset is used already?

Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/561672EB.3070807%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Formset questions: data vs. initial values

2015-10-06 Thread Carsten Fuchs


Anyone please?

Best regards,
Carsten


Am 07.09.2015 um 21:18 schrieb Carsten Fuchs:

Dear Django group,

after having read all of the Django docs that I could find, I still have two 
questions
about the proper use of formsets. Summary first:

   1. What is a good way to make sure the data received in the POST request 
agrees with
the "initial" data (number of items and items order is as expected)?

   2. What is a good way to augment each form with additional data that is only 
used for
decoration (rendering additional information) in the template, but is not a 
form field?


More details:

In a single view, I would like to let the user edit calendar entries, i.e. one 
CharField
value for each day in a month. The related model is:


 from django.db import models

 class CalendarEntry(models.Model):
 ref_date = models.DateField()
 entry= models.CharField(max_length=40, blank=True)


An important issue is that we don't create an instance of CalendarEntry for 
each day in
a month, but only for those that actually have an entry! However, the formset 
that is
presented to the user should of course have one "entry" field for each day in 
the month
(properly initialized if we have a related CalenderEntry instance, blank 
otherwise).

Thus, it seems that a ModelForm for CalendarEntry cannot be used, because we 
need some
forms for which a CalendarEntry instance does not exist, but the form instance 
must
still exist and be initialized with a date (and an empty "entry" field).

Therefore, I made a simple form like this, mimicing the model:


 from django import forms

 class ExampleForm(forms.Form):
 ref_date = forms.DateField(widget=forms.HiddenInput())
 entry= forms.CharField(required=False, max_length=40)


The date field is hidden, because the user is not supposed to change it. But we 
need it
for reference later, when the POST data is processed. (It could possibly be 
omitted in
this example, but if this was not the days in a month but the students in a 
class, it
would be the only reliable reference connecting the value to the student.)

Now, let's suppose I came up with a list of initial values, both when the 
formset is
first created in the GET request, and also later when the data is submitted in 
the POST
request. For example like this:


 # Example is specific to September:
 from datetime import date
 september_inits = [{"ref_date": date(2015, 9, i + 1)} for i in range(30)]

 for ce in CalendarEntry.objects.filter(ref_date__year=2015, 
ref_date__month=9)
 september_inits[ce.ref_date.day-1]["entry"] = ce.entry


Now the view is implemented like this:


from django.forms.formsets import formset_factory
from django.shortcuts import render_to_response
from myapp.forms import ExampleForm

def example_view(request):
 september_inits = [...]   # as above
 ExampleFormSet = formset_factory(ExampleForm)

 if request.method == 'POST':
 formset = ExampleFormSet(request.POST)

 # ~ Question 1 ~
 # What is the best way (or: a proper way) to check if formset
 # agrees to september_inits? Can I use
 # formset = ExampleFormSet(request.POST, initial=september_inits)
 # then follow
https://docs.djangoproject.com/en/1.8/topics/forms/formsets/#custom-formset-validation
 ?
 # If so, how to access the "initial" data??

 if formset.is_valid():
 # ...
 pass
 else:
 formset = ExampleFormSet(initial=september_inits)

 # ~ Question 2 ~
 # What is the best way (or: a proper way) to add per-form information,
 # e.g. "September 24th is a holiday"?

 return render_to_response('manage_articles.html', {'formset': formset})


The two questions have been reformulated as comments above.
Any help would very much be appreciated!

Many thanks and best regards,
Carsten



--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5613FEC0.7080704%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Converting implicit m2m through table to explicit through model with Django 1.7 migrations

2015-10-03 Thread Carsten Fuchs


Am 2015-10-02 um 23:28 schrieb John Lucas:

Thanks for the replies. Carsten - that link is broken for me unfortunately.


Sorry, this seems to be a problem with gmane.

The same thread at Google groups is here:
https://groups.google.com/d/msg/django-users/K0X8P3s3DOw/cH5PDxYjLtYJ

Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/560F8187.2090600%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Converting implicit m2m through table to explicit through model with Django 1.7 migrations

2015-09-29 Thread Carsten Fuchs


Hi John,

Am 28.09.2015 um 15:54 schrieb John Lucas:

So - is my approach safe? Or will there be complications down the line?


I've recently had a similar / the same question. See this thread, which also contains 
the solution that worked very well for me:

http://thread.gmane.org/gmane.comp.python.django.user/172038

Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/560AB725.30509%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Advanced Annotate

2015-09-17 Thread Carsten Fuchs


Hi Paolo,

Am 16.09.2015 um 22:52 schrieb Paolo C.:

[...], I need to annotate not only the price but also which is the book that
has that max value.


Isn't that exactly what I was wondering about, too?

	"1) Is there a way to annotate each Store object with the actual Book objects related 
to the minimum and maximum prices?"


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55FAEAB1.7050800%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Advanced Annotate

2015-09-16 Thread Carsten Fuchs


Hi Paolo,

Am 15.09.2015 um 00:32 schrieb Paolo C.:

How can obtain details from the last comment when listing ll posts?


If I understood your question correctly -- I recently had the same question, see 
https://groups.google.com/d/msg/django-users/adRe2_BWMz0/G71BVUEI_7oJ for details.


It seems that the so far best answer is described at 
http://blog.roseman.org.uk/2010/08/14/getting-related-item-aggregate/


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55F9753D.4030105%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Formset questions: data vs. initial values

2015-09-07 Thread Carsten Fuchs


Dear Django group,

after having read all of the Django docs that I could find, I still have two questions 
about the proper use of formsets. Summary first:


  1. What is a good way to make sure the data received in the POST request agrees with 
the "initial" data (number of items and items order is as expected)?


  2. What is a good way to augment each form with additional data that is only used for 
decoration (rendering additional information) in the template, but is not a form field?



More details:

In a single view, I would like to let the user edit calendar entries, i.e. one CharField 
value for each day in a month. The related model is:



from django.db import models

class CalendarEntry(models.Model):
ref_date = models.DateField()
entry= models.CharField(max_length=40, blank=True)


An important issue is that we don't create an instance of CalendarEntry for each day in 
a month, but only for those that actually have an entry! However, the formset that is 
presented to the user should of course have one "entry" field for each day in the month 
(properly initialized if we have a related CalenderEntry instance, blank otherwise).


Thus, it seems that a ModelForm for CalendarEntry cannot be used, because we need some 
forms for which a CalendarEntry instance does not exist, but the form instance must 
still exist and be initialized with a date (and an empty "entry" field).


Therefore, I made a simple form like this, mimicing the model:


from django import forms

class ExampleForm(forms.Form):
ref_date = forms.DateField(widget=forms.HiddenInput())
entry= forms.CharField(required=False, max_length=40)


The date field is hidden, because the user is not supposed to change it. But we need it 
for reference later, when the POST data is processed. (It could possibly be omitted in 
this example, but if this was not the days in a month but the students in a class, it 
would be the only reliable reference connecting the value to the student.)


Now, let's suppose I came up with a list of initial values, both when the formset is 
first created in the GET request, and also later when the data is submitted in the POST 
request. For example like this:



# Example is specific to September:
from datetime import date
september_inits = [{"ref_date": date(2015, 9, i + 1)} for i in range(30)]

for ce in CalendarEntry.objects.filter(ref_date__year=2015, 
ref_date__month=9)
september_inits[ce.ref_date.day-1]["entry"] = ce.entry


Now the view is implemented like this:


from django.forms.formsets import formset_factory
from django.shortcuts import render_to_response
from myapp.forms import ExampleForm

def example_view(request):
september_inits = [...]   # as above
ExampleFormSet = formset_factory(ExampleForm)

if request.method == 'POST':
formset = ExampleFormSet(request.POST)

# ~ Question 1 ~
# What is the best way (or: a proper way) to check if formset
# agrees to september_inits? Can I use
# formset = ExampleFormSet(request.POST, initial=september_inits)
# then follow 
https://docs.djangoproject.com/en/1.8/topics/forms/formsets/#custom-formset-validation ?

# If so, how to access the "initial" data??

if formset.is_valid():
# ...
pass
else:
formset = ExampleFormSet(initial=september_inits)

# ~ Question 2 ~
# What is the best way (or: a proper way) to add per-form information,
# e.g. "September 24th is a holiday"?

return render_to_response('manage_articles.html', {'formset': formset})


The two questions have been reformulated as comments above.
Any help would very much be appreciated!

Many thanks and best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55EDE307.8000704%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Transaction questions

2015-07-27 Thread Carsten Fuchs


Hi all,

using Django 1.8.3, at this time I have code like this:


try:
mm = TestMonthModel.objects.select_for_update().get(jahr=Jahr, 
monat=Monat)
except TestMonthModel.DoesNotExist:
mm = TestMonthModel(jahr=Jahr, monat=Monat)

# A *long* computation, eventually setting fields in mm and save:

mm.value = 123
mm.save()


With the select_for_update(), this should block any concurrent calls and thus prevent 
race conditions whenever the mm object already exists.


But what if it doesn't, and is only created in the except-clause?

There is a  unique_together = (jahr, monat)  database constraint in place, and thus a 
concurrent call to mm.save() would see an IntegrityError for newly created mm objects, 
but I wonder if a lock can be acquired after object creation?  For example:



try:
mm = TestMonthModel.objects.select_for_update().get(jahr=Jahr, 
monat=Monat)
except TestMonthModel.DoesNotExist:
mm = TestMonthModel(jahr=Jahr, monat=Monat)

# This is not atomic... is there a better way?
mm.value = 0# Db constraint, cannot be NULL, so fill in some 
defaults...
mm.save()
mm = TestMonthModel.objects.select_for_update().get(id=mm.id)

# Rest as above:
# A *long* computation, eventually setting fields in mm and save:

mm.value = 123
mm.save()


Is  select_for_update().get_or_create(...)  an option here?

Many thanks and best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55B6788A.3000804%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Migrate a many-to-many field to an explicit intermediate ("through") model?

2015-07-24 Thread Carsten Fuchs


Hi all,

just wanted to let you know that I was successful!

I followed Gergely's final recipe, using RunPython for the data migrations and separate 
migration files for each of the steps.


For step 3 (the deletion of the ManyToManyField) I temporarily had to remove the 
django.contrib.admin from the INSTALLED_APPS, because I was referring to the old 
ManyToManyField in my app's admin.py setup, which in turn was processed while running 
`./manage.py makemigrations`.


Overall, this worked very well.

Many thanks to you both for your help!
:-)

Am 23.07.2015 um 22:37 schrieb Carl Meyer:

Meanwhile it might worth a question to the devs (or a more thorough
search on the topic) to understand why you can't switch from a simple
m2m field to one with a through option.


Just because it's a bit complex to implement, and nobody has implemented
it yet.


Well, if I understand this correctly, https://code.djangoproject.com/ticket/23034 has a 
reviewed PR that implements this, but unfortunately the original author has not updated 
the PR for several months...


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55B2814E.1090604%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Admin login template at admin/login.html instead of registration/login.html?

2015-07-24 Thread Carsten Fuchs


Hi Carl,

Am 23.07.2015 um 20:07 schrieb Carl Meyer:

Of course it's _possible_ to have just a single login page instead, if
you want that, but it's not at all clear to me that that's better. I
prefer to keep the admin relatively separate from the public site.

And I think the same is true for password-reset etc. I'd prefer to leave
the admin with its own pages, styled consistently with the rest of the
admin, and design my own pages for public users, consistent with the
design of the rest of the public site.


Yes, I certainly see your point. If I could start all over with my first (and now major) 
Django project, or in the mid-term future, I'd probably also do it like this.



Allow me to add some background info:

When I started with Django and worked through the tutorials, augmenting and building my 
first project in the process, it was very nice to get quick success and highly useful 
results with the Django Admin. Also the first custom view was quickly written thanks to 
the forms and templates features.


But... while I understand HTML and CSS at a logical level, I'm a horrible web designer. 
For my first view and its related template, I quasi had nothing; no basis that looked 
anywhere near visually acceptable, especially none that came with a nice top navigation 
bar, user links, etc. And so what did I do, against all advice and documentation? I used 
the Admin templates as a basis for my custom views. (I hope than anyone will ever talk 
to me again after this.  ;-) )


Worse, soon I had a model that I wanted users to be able to deal with almost like 
administrators: (View,) create, edit, and delete instances at will. The only difference 
to "real" is_staff admins was a filtered/limited QuerySet. But with changelists that 
support pagination, filtering, sorting and searching.


Really, until today I have no idea how I can achieve (i.e. duplicate) such functionality 
in custom user views (without reinventing the wheel). (Maybe class-based views can do 
that, I'm still with classic function-based views, and I really don't know if this makes 
a difference.)


And so I got where I am now: Most of my regular users are also admin users, and they 
don't even know the difference.


And so while I strive to get things properly separated again, I bridge the time by using 
common designs at least for the custom and admin auth views. (Bootstrap is really 
perfect for me, I wished I had it available from the very beginning. Would then never 
have used the admin templates in custom views in the first place.)



Presuming we made the admin use its own templates for all of this, you
could achieve what you want by also overriding the admin templates and
just making them inherit everything from your templates. A tiny bit of
boilerplate, but not much.


Yes. Indeed, thanks to the AdminSite object, in an app's admin.py file, even a 
simple

admin.site.login_template = "registration/login.html"

is enough – this is the exact live code that I use now to override the 
"admin/login.html" default.



Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55B24485.3030508%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Admin login template at admin/login.html instead of registration/login.html?


Hi Tim,

many thanks for your reply!

Am 23.07.2015 um 18:49 schrieb Tim Graham:

The admin login only allows staff users to login so it makes sense to me that 
if you
wanted to add regular user login to your site, it should have separate URLs.


I think what confuses me is the fact that (in the Auth app) there is only one User 
model, and the only difference between regular and staff users is the User.is_staff flag.


For example, if a staff user logs out of the Admin, he is logged out as a regular user 
as well. If a regular user logs in via a custom login page, then browses to an Admin 
page, some kind of error report or redirect must occur.


Given this, authentication is like a user-centric, site-wide feature rather than an 
app-specific one, isn't it?



As for the template issue, it seems to me the admin/template/registration 
templates
should be more like admin/login.html and namespaced under admin so that if you 
want to
implement a non-admin password reset, you don't have a conflict in the template 
names
(see the ticket below for an example).

https://code.djangoproject.com/ticket/20372



Well, I am quite happy about the admin using the registration/... templates by default: 
With the view that authentication is user- rather than app-specific, I recently made my 
admin and regular logins look identical, which worked very well.

So ticket 20372 is quite the opposite of my view.  ;-)

In fact, I'd even prefer if the admin came with no auth dependency at all. I'm aware 
that that would make getting started harder (and easily getting started was one of the 
things I was very grateful for while taking my first steps with Django!), but if the 
admin and auth were explicitly separate, it would also remove all confusion both in the 
spirit of ticket 20372 and the opposite of it.


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55B12743.7090909%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Migrate a many-to-many field to an explicit intermediate ("through") model?


Hi Carl,

Am 23.07.2015 um 18:28 schrieb Carl Meyer:

Overall I think it might be simpler to go with your initial approach. I'd first 
rename
the old field to some other temporary name (you don't have to update any other 
code to
use this name, as you'll commit all of these migrations in one commit, so 
nothing but
the following data migration ever needs to know anything about this temporary 
name),


Thanks for clarifying the details regarding renaming! With this, this is the approach 
that I feel the most comfortable with and will try now.


Overall, many thanks for your thoughts and your detailed reply, it's very much 
appreciated and helps a lot!


Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55B11F7B.1010805%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Migrate a many-to-many field to an explicit intermediate ("through") model?


Am 16.07.2015 um 16:05 schrieb Carsten Fuchs:

Alas... are there any viable alternatives to this?
I'd be very grateful for any hint!   :-)



Anyone please?

Best regards,
Carsten

--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55B10E2A.7060809%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Why is Admin login template at admin/login.html instead of registration/login.html?