Re: how to copy data per user

[Jun Tanaka]

Hello Tim,

2015年10月7日水曜日 21時36分59秒 UTC+9 Tim Graham:
>
> I don't think you've provided enough details about your models for anyone 
> to provide an answer.
>
> Probably, you are right. Simply, any model with below for per users is 
fine. 

from django.contrib.auth.models import User



Say something like,


from django.db import modelsfrom django.contrib.auth.models import User
 class UserProfile(models.Model):
url = models.URLField()
home_address = models.TextField()
phone_numer = models.PhoneNumberField()
user = models.ForeignKey(User, unique=True)


http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/

 

> p.s. Django 1.6 is unsupported and has unfixed security vulnerabilities so 
> you should try to upgrade to a supported version.
> https://www.djangoproject.com/download/#supported-versions
>
>
Thank you for pointing it. 

-- 
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/6e998fda-8cb3-4c33-b7d3-fae5ef749c0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to copy data per user

[Stephen J. Butler]

Lots of ways to do it. Maybe most efficient is:

UserProfile.objects.filter(user__in=u_dst).update(url=up_src.url,
home_address=up_src.home_address, phone_number=up_src.phone_number)

Where u_dst is a list/tuple/iterable of destination users, and up_src is
the UserProfile of the source user.

On Thu, Oct 8, 2015 at 2:19 AM, Jun Tanaka  wrote:

> Hello Tim,
>
> 2015年10月7日水曜日 21時36分59秒 UTC+9 Tim Graham:
>>
>> I don't think you've provided enough details about your models for anyone
>> to provide an answer.
>>
>> Probably, you are right. Simply, any model with below for per users is
> fine.
>
> from django.contrib.auth.models import User
>
>
>
> Say something like,
>
>
> from django.db import modelsfrom django.contrib.auth.models import User
>  class UserProfile(models.Model):
> url = models.URLField()
> home_address = models.TextField()
> phone_numer = models.PhoneNumberField()
> user = models.ForeignKey(User, unique=True)
>
>
> http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/
>
>
>
>> p.s. Django 1.6 is unsupported and has unfixed security vulnerabilities
>> so you should try to upgrade to a supported version.
>> https://www.djangoproject.com/download/#supported-versions
>>
>>
> Thank you for pointing it.
>
> --
> 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/6e998fda-8cb3-4c33-b7d3-fae5ef749c0b%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAD4ANxW3krEu2-kwidi8kkaADcNgsEV940jdY3kW63YWH4p%3D-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Using South in Django 1.7+

[Remco Gerlich]

I want to run South migrations in a Django 1.7+ installation. I know that's
now how it's usually done, but we have a special needs use case.

Our users have SQLite files that model their project; the SQL schema used
has changed over time, and users are on many different versions.

Our application is a Django 1.6 site. They provide their files to our
application, it changes the Django settings so that one of the databases
refers to their SQLite file, and we run South on it to get the schema to
the current version. Then our app does its actual work. The users continue
to refine their models with their old-schema sqlite files.

Now we want to upgrade our Django version, but we need continue to be able
to apply our old migrations :-(.

Can South run on Django 1.7+ at all?

If not, maybe we have to keep some 1.6 installation running somewhere on
the backend to upgrade a file to the current situation, and then apply new
migrations from there...

Greetings,
Remco Gerlich

-- 
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/CAFAGLK12AWrkq8Wc5Y7SQF885H6apNymQW1C5H8wAjjVpDBDSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Formset questions: data vs. initial values

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

formset concurrency control

[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: Using South in Django 1.7+

[Carl Meyer]

Hi Remco,

On 10/08/2015 04:26 AM, Remco Gerlich wrote:
[snip]
> Can South run on Django 1.7+ at all?

Nope. At least not last I tried, and I don't think anyone has done
anything on it since. It looked like it would need some major updating,
since South integrates closely with the database backends and they
changed in a big way in 1.7.

> If not, maybe we have to keep some 1.6 installation running somewhere on
> the backend to upgrade a file to the current situation, and then apply
> new migrations from there...

Yes, I think that's probably your best bet. You could try your hand at
porting South to 1.7, but I wouldn't expect it to be easy.

Carl

-- 
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/56167ABB.1030102%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Flakey tests and django.db.utils.InterfaceError: connection already closed

[thinkwell]

I could use some assistance in troubleshooting a psycopg2.InterfaceError 
problem that has erratic behavior. Here is the test module 
 suite that I'm running to test these models 
, and in this state all the tests in the 
module pass. However, it's extremely easy to trigger a 
psycopg2.InterfaceError, although not relating to the lines changed. For 
example, if I change:

class TestSilly(SimpleTestCase): 
  
def test_is_not_false(self): 
self.assertTrue(False is not True)


to 

class TestSilly(TestCase): 
  
def test_is_not_false(self): 
self.assertTrue(False is not True)

  

Then this error is raised, but referencing TestPolicyModel instead of 
TestSilly!

==
ERROR: test_toggle_autofix (accounts.tests.test_models.TestPolicyModel)
--
Traceback (most recent call last):
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
line 137, in _cursor
return self.create_cursor()
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/backends/postgresql_psycopg2/base.py"
, line 212, in create_cursor
cursor = self.connection.cursor()
psycopg2.InterfaceError: connection already closed

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "apps/accounts/tests/test_models.py", line 174, in 
test_toggle_autofix
p = Policy.objects.first()
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/manager.py", 
line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py", 
line 490, in first
objects = list((self if self.ordered else self.order_by('pk'))[:1])
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py", 
line 162, in __iter__
self._fetch_all()
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py", 
line 965, in _fetch_all
self._result_cache = list(self.iterator())
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py", 
line 238, in iterator
results = compiler.execute_sql()
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/models/sql/compiler.py", 
line 838, in execute_sql
cursor = self.connection.cursor()
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
line 164, in cursor
cursor = self.make_cursor(self._cursor())
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
line 137, in _cursor
return self.create_cursor()
  File "/usr/local/lib/python3.4/dist-packages/django/db/utils.py", line 97, 
in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/usr/local/lib/python3.4/dist-packages/django/utils/six.py", line 
658, in reraise
raise value.with_traceback(tb)
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
line 137, in _cursor
return self.create_cursor()
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/backends/postgresql_psycopg2/base.py"
, line 212, in create_cursor
cursor = self.connection.cursor()
django.db.utils.InterfaceError: connection already closed


For another example, if I change 

TestPolicyModel(TestCase)


to

TestPolicyModel(SimpleTestCase)


then, I get the following error regarding TestRedwoodModel

==
ERROR: setUpClass (accounts.tests.test_models.TestRedwoodModel)
--
Traceback (most recent call last):
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
line 137, in _cursor
return self.create_cursor()
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/backends/postgresql_psycopg2/base.py"
, line 212, in create_cursor
cursor = self.connection.cursor()
psycopg2.InterfaceError: connection already closed

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "apps/accounts/tests/test_models.py", line 195, in setUpClass
cls.ru = RedwoodUsers.objects.first()
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/manager.py", 
line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py", 
line 490, in first
objects = list((self if self.ordered else self.order_by('pk'))[:1])
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py", 
line 162, in __iter__
self._fetch_all()
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py", 
line 965, in _fetch_all
self._result_cache = list(self.iterator())
  File "/usr/local/lib/python3.4/dist-packages/django/db/mode

wsgi.py apache segmentation fault

[Eugenio Trumpy]

Hello everybody,

I'm very not so expert on django, I'm at the first experience.
I'm using django as backhand of geonode application.

Geonode works quite fine, however during a save map request from client 
side I got this apache2 segmentation fault:

[Thu Oct 08 15:30:38.037330 2015] [core:error] [pid 10101] [client 
X.X.X.X:50787] End of script output before headers: wsgi.py, referer: 
http://my_server_name/maps/new
[Thu Oct 08 15:30:38.292052 2015] [core:notice] [pid 2697] AH00052: child 
pid 10004 exit signal Segmentation fault (11)

I discovered this page on similar issue:

https://code.google.com/p/modwsgi/wiki/FrequentlyAskedQuestions

but I checked and I have not the mod_python installed.

Can somebody give me hints on how to solve this problem?

Best

Eugenio

-- 
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/b6dd00de-1d31-41ad-b2ee-f513abd63c12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Overriding template view function in Django app.

[sonu kumar]

I have installed third party app(Mezzanine) whose urls are configured to 
use their view functions not View Class. Source code from 
mezzanine.blog.urls

   urlpatterns = patterns("mezzanine.blog.views",16 

   url("^%stag/(?P.*)%s$" % _slashes, "blog_post_list",

21 

name="blog_post_list_tag"),

18 

 
... 44 

)

As we can see they have configured blog URLs to use mezzanine.blog.views. Here 
we have few functions which are being called by URL dispatcher.  one of them is 
below.

*   def* blog_post_list(request 
, tag 
=*None*, year 
=*None*, month 
=*None*, username 
=*None*,20 

   category 
=*None*, 
template="blog /blog_post_list.html 
",21 

   extra_context 
=*None*):22 

"""23 

Display a list of blog posts that are filtered by tag, year, month,24 

author or category. Custom templates are checked for using the name25 

``blog /blog_post_list_XXX.html 
`` where 
``XXX`` is either the26 

category slug or author's username if given.27 

"""

I would like to override this function so that it will call my function to 
update context dictionary  or pass some more arguments to default function 
blog_post_list (it's having an argument extra_context so we can use this as 
external context) 


How can I achieve this ?

 Please provide complete details like do we have to modify urlpatterns then 
what should be changed, if we have to change view then what should be change ?

-- 
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/47eabec2-fdb1-47a8-b9f8-8f158c29852f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

formset concurrency control

[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?
-- 
DR.

-- 
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/05eb179c-f621-4ef9-9997-744f73a56bff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: "RuntimeError: Error creating new content types."

[Roger Hunwicks]

On 1.8 `--fake-initial` only works if you have a single initial migration 
per app. We don't because we have additional migrations to load data and 
create database triggers, etc.

In 1.9 this will be handled by the `initial = True`  setting on the 
Migration class.

Until then, we are using:

./manage.py migrate --fake-initial contenttypes
./manage.py migrate --fake

Of course this relies on you being certain that your existing database is 
exactly the same as it would be if all the migrations were applied to an 
empty database and there is no sanity-checking.

-- 
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/0110001f-a43e-47b4-8704-2cc0ab7a92f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: formset concurrency control

[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. :-)

On Thursday, October 8, 2015 at 12:48:34 PM UTC-4, Daniel Roseman wrote:
>
> 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?
> -- 
> DR.

-- 
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/310029cd-1fb5-4b75-bf8b-eb5fd7924bf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: formset concurrency control

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