CSRF_COOKIE_SECURE and SESSION_COOKIE_SECURE to True when terminating SSL on load balancer

[pjotr]

Hi,

I use HAProxy as load balancer, where I also terminate the SSL. The traffic 
between HAProxy and the is unencrypted. I have force SSL enabled, so all 
requests with http will be redirected to https.

Question is, does it serve any good to have CSRF_COOKIE_SECURE 
and SESSION_COOKIE_SECURE set to True in settings? It doesn't make sense 
for me, but there might be some other reasons for using that!?

/Peter

-- 
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/a5d82347-5d4f-481f-8bc5-94be751f9f71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Approaches for sharing development fixtures across teams

[pjotr]

Hi,

We have been struggling with sharing development fixtures between each 
other. Keeping media files, and db in sync has been problematic for us. We 
started by just storing zip files containing media files directory, and a 
pg_dump of the database. Fine. But then we started to swap branches, db got 
out of sync, swapping/changing/deleting migrations in feature branches due 
to changing in models, etc etc...

I ended up writing a management, that relies on that git, and a set of 
other tools are installed. It includes auto detection when restoring 
fixtures, and of course dev fixtures with tagged commit ids.

Does anyone else have other approaches? Other packages around?

The first release, that is working well for us right now, can be found 
here: https://github.com/dolphinkiss/django-devfixtures

And of course on pypi: https://pypi.python.org/pypi/django-devfixtures

And docs: http://django-devfixtures.readthedocs.org/en/latest/

It has its limitations, but a clear approach. But there might be better 
approaches?

/Peter

-- 
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/2eb8745e-b7b0-4efd-b5a4-6479b9763cf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrate adds multiple migrations.AddField for same model (django 1.7.1)

[pjotr]

I created ticket for this: https://code.djangoproject.com/ticket/24203

On Friday, December 26, 2014 at 9:54:52 PM UTC+1, Collin Anderson wrote:
>
> Ohh, I see. Yes, this looks like a possible spot for optimization. I 
> wouldn't really call it a "bug", but a "cleanup/optimization". You could 
> probably open a ticket about it.
>
> On Tuesday, December 23, 2014 5:04:55 AM UTC-6, pjotr wrote:
>>
>> Sorry, all the ALTER statements are identical except the FIELDNAME. It 
>> adds 6 new fields.
>>
>> On Tuesday, December 23, 2014 4:46:42 AM UTC+1, Collin Anderson wrote:
>>>
>>> Hi,
>>>
>>> You're just using one database?
>>>
>>> Are all 6 ALTER statements identical?
>>>
>>> Collin
>>>
>>> On Sunday, December 21, 2014 5:27:06 PM UTC-6, pjotr wrote:
>>>>
>>>> Just realized the subject was wrong, it should be *makemigrations , 
>>>> not makemigrate*
>>>>
>>>> On Sunday, December 21, 2014 8:36:29 PM UTC+1, pjotr wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have a django model that I just added six new fields to. I ran 
>>>>> *makemigrations 
>>>>> *and after that noticed when we ran our rehearsal upgrade with dump 
>>>>> of the production database that things took longer than we expected, and 
>>>>> checked the processlist. We saw that there were six *alter table* 
>>>>> statements that was executed after each other, each taking around 15 
>>>>> minutes to run.
>>>>>
>>>>> My expectations were that the migration framework would optimise this 
>>>>> and only execute one alter table statement. But obviously it was not. Or 
>>>>> is 
>>>>> there a bug? :)
>>>>>
>>>>> Are there anyway to fix this, without having to change the migration 
>>>>> and perform the alter table statement with pure SQL?
>>>>>
>>>>> DB: MySQL
>>>>> Django 1.7.1
>>>>>
>>>>> The migrations generated were six of these (only showing one to reduce 
>>>>> post size):
>>>>>
>>>>> migrations.AddField(
>>>>> model_name='mymodel',
>>>>> name='field_a',
>>>>> field=models.BigIntegerField(help_text=b'Blablabla', null=True, 
>>>>> db_index=True),
>>>>> preserve_default=True,
>>>>> ),
>>>>>
>>>>>
>>>>> Regards, Peter Lauri
>>>>>
>>>>>

-- 
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/0fa8caba-018b-4617-b527-7a8d6b0dd3c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrate adds multiple migrations.AddField for same model (django 1.7.1)

[pjotr]

Sorry, all the ALTER statements are identical except the FIELDNAME. It adds 
6 new fields.

On Tuesday, December 23, 2014 4:46:42 AM UTC+1, Collin Anderson wrote:
>
> Hi,
>
> You're just using one database?
>
> Are all 6 ALTER statements identical?
>
> Collin
>
> On Sunday, December 21, 2014 5:27:06 PM UTC-6, pjotr wrote:
>>
>> Just realized the subject was wrong, it should be *makemigrations , not 
>> makemigrate*
>>
>> On Sunday, December 21, 2014 8:36:29 PM UTC+1, pjotr wrote:
>>>
>>> Hi,
>>>
>>> I have a django model that I just added six new fields to. I ran 
>>> *makemigrations 
>>> *and after that noticed when we ran our rehearsal upgrade with dump of 
>>> the production database that things took longer than we expected, and 
>>> checked the processlist. We saw that there were six *alter table* 
>>> statements that was executed after each other, each taking around 15 
>>> minutes to run.
>>>
>>> My expectations were that the migration framework would optimise this 
>>> and only execute one alter table statement. But obviously it was not. Or is 
>>> there a bug? :)
>>>
>>> Are there anyway to fix this, without having to change the migration and 
>>> perform the alter table statement with pure SQL?
>>>
>>> DB: MySQL
>>> Django 1.7.1
>>>
>>> The migrations generated were six of these (only showing one to reduce 
>>> post size):
>>>
>>> migrations.AddField(
>>> model_name='mymodel',
>>> name='field_a',
>>> field=models.BigIntegerField(help_text=b'Blablabla', null=True, 
>>> db_index=True),
>>> preserve_default=True,
>>> ),
>>>
>>>
>>> Regards, Peter Lauri
>>>
>>>

-- 
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/c598973a-d928-4396-8b62-2082d4a57c57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrate adds multiple migrations.AddField for same model (django 1.7.1)

[pjotr]

Just realized the subject was wrong, it should be *makemigrations , not 
makemigrate*

On Sunday, December 21, 2014 8:36:29 PM UTC+1, pjotr wrote:
>
> Hi,
>
> I have a django model that I just added six new fields to. I ran 
> *makemigrations 
> *and after that noticed when we ran our rehearsal upgrade with dump of 
> the production database that things took longer than we expected, and 
> checked the processlist. We saw that there were six *alter table* 
> statements that was executed after each other, each taking around 15 
> minutes to run.
>
> My expectations were that the migration framework would optimise this and 
> only execute one alter table statement. But obviously it was not. Or is 
> there a bug? :)
>
> Are there anyway to fix this, without having to change the migration and 
> perform the alter table statement with pure SQL?
>
> DB: MySQL
> Django 1.7.1
>
> The migrations generated were six of these (only showing one to reduce 
> post size):
>
> migrations.AddField(
> model_name='mymodel',
> name='field_a',
> field=models.BigIntegerField(help_text=b'Blablabla', null=True, 
> db_index=True),
> preserve_default=True,
> ),
>
>
> Regards, Peter Lauri
>
>

-- 
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/c6a523ee-07b8-4a50-8e3b-55ed623e5663%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

makemigrate adds multiple migrations.AddField for same model (django 1.7.1)

[pjotr]

Hi,

I have a django model that I just added six new fields to. I ran 
*makemigrations 
*and after that noticed when we ran our rehearsal upgrade with dump of the 
production database that things took longer than we expected, and checked 
the processlist. We saw that there were six *alter table* statements that 
was executed after each other, each taking around 15 minutes to run.

My expectations were that the migration framework would optimise this and 
only execute one alter table statement. But obviously it was not. Or is 
there a bug? :)

Are there anyway to fix this, without having to change the migration and 
perform the alter table statement with pure SQL?

DB: MySQL
Django 1.7.1

The migrations generated were six of these (only showing one to reduce post 
size):

migrations.AddField(
model_name='mymodel',
name='field_a',
field=models.BigIntegerField(help_text=b'Blablabla', null=True, 
db_index=True),
preserve_default=True,
),


Regards, Peter Lauri

-- 
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/d0f6553c-e21b-4f2b-97d5-7c9aa7634375%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redirect user inside Class-Based views

[pjotr]

You could also look into django-braces that has some mixins to handle some 
common operations.

http://django-braces.readthedocs.org/en/latest/index.html


On Tuesday, December 2, 2014 4:10:40 PM UTC+1, Rootz wrote:
>
> thanks
>
> On Tuesday, December 2, 2014 9:22:32 AM UTC-5, Andréas Kühne wrote:
>>
>> 2014-12-02 15:17 GMT+01:00 Rootz :
>>
>>> I have a small Django App using several Class-Based Views but I am 
>>> contemplating how the class views would redirect a user based upon a 
>>> condition? In my case I would like to redirect user who are not 
>>> authenticated. Just how do I go about doing that?
>>>
>>> thanks
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/57d8f675-5336-421a-9f36-aee6e24545ff%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> As long as the class based view doesn't require you to be logged in you 
>> can achive that by doing:
>>
>> def dispatch(self, request, *args, **kwargs):
>> if not request.user.is_authenticated():
>> return HttpResponseRedirect(reverse("url_name_to_redirect_to"))
>>
>> # Continue with other dispatch functionality
>>
>> Regards,
>>
>> Andréas
>>
>

-- 
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/8818b8ce-587e-4a5b-b717-c91b38347e95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to restrict save function in Django admin

[pjotr]

Maybe you could show the code to clearly see what you are doing?

On Wednesday, December 3, 2014 6:03:56 AM UTC+1, Akshay Mukadam wrote:
>
> Hi,
> I have developed application that loads CSV file, if the input received 
> while parsing the CSV file in Django admin is wrong, it throws a 
> stacktrace, to avoid stacktrace I have handled the exception and I am able 
> to show the error message using the Message framework in django. 
> But the problem is that when I save the data it shows the error that CSV 
> data is incorrect, but it also show save message, how could I override 
> this.???
> Thank You
>

-- 
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/7d882bea-81cb-43ec-a42c-9e1e0ecefbc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: template url reverse and namespacing is driving me crazy

[pjotr]

That is not the point. I know I can do that, but that doesn't solve the 
issue of an reusable app. I could fork the 'greeter' project, add my 
namespace in the templates, and it would be all working. But still that is 
not the point.

The point is: how can I write a reusable app so that someone else, that 
uses it can namespace it into whatever namespace they want, and it should 
still work.


On Monday, December 1, 2014 4:35:53 AM UTC+1, WongoBongo wrote:
>
> Change all instances of this in your templates
>
> {% url 'greet' greeter.pk %}
>
> To this
>
> {% url 'greeter:greet' greeter.pk %}.
>
> Since you are now using the 'greeter' namespace. Also, the other one is 
>
> {% url 'greeter:list' %} and not {% url 'list' %} because you are using 
> the 'greeter' namespace.
>
> K
>
> On Sunday, November 30, 2014 11:51:17 AM UTC-8, pjotr wrote:
>>
>> Alright, I'm already crazy, so the subject is a bit of a lie. But 
>> nevermind.
>>
>> I think I like namespacing, it is really nice. But there is something not 
>> that clear in the documentation of Django, and how to make usage of 
>> namespace, in a consistent way. Lets take it by example.
>>
>> I'm using this pretty amazing app "greeter" that was written by a 
>> superuser from a country far away from my own. It is a pretty simple app, 
>> that has two url mappings:
>>
>> url(r'^list/$', HelloWorldList.as_view(), name='list'),
>> url(r'^greet/(?P\d+)/$', HelloWorldGreet.as_view(), name='greet'),
>>
>>
>> The template of HelloWorldList view is using the template tag url like this: 
>> {% url 'greet' greeter.pk %}.
>>
>> After that I hook up the application in my project by including it in my 
>> project urls.py:
>>
>> url(r'^greeter/', include('greeter.urls')),
>>
>>
>> Everything works well, I felt like a Django guru integrating the hello 
>> world app to my own project. I can access /greeter/list and clicking on the 
>> greetings works well.
>>
>> Later that night I go to bed, feeling confident, kissing my wife 
>> goodnight with a smile on my face. I wake up warm, sweaty, with my heart 
>> beating. I run to my laptop, just realized I forgot to namespace the greet 
>> app, because I just realized I am using the list name in another place in 
>> my project, and I don't have any automated tests, so I better namespace it 
>> quickly.
>>
>> So, I change my project url mapping to this:
>>
>> url(r'^greeter/', include('greeter.urls', namespace='greeter')),
>>
>>
>> Boom crash. Visiting the /greeter/list/ page gives me:
>>
>>
>> Reverse for 'greet' with arguments '()' and keyword arguments '{pk:1}' not 
>> found. 0 pattern(s) tried: []
>>
>>
>> I start to doubt the author of the 'greeter' app, that he didn't prepare his 
>> app for being used in other projects, where the project might need 
>> namespacing to avoid conflicts.
>>
>>
>> Digging into Django documentation, I don't really find any argument for the 
>> author of the 'greeter' app to be sloppy and not caring of details.
>>
>>
>> Someone who can enlighten me why django doesn't try to default to the 
>> current app when resolving namespaces? Or can someone enlighten me how I can 
>> help out the author of the 'greeting' app, so it really is reusable in other 
>> projects?
>>
>>

-- 
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/4f2246c6-8711-4d76-a17a-67cc417a5019%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

template url reverse and namespacing is driving me crazy

[pjotr]

Alright, I'm already crazy, so the subject is a bit of a lie. But nevermind.

I think I like namespacing, it is really nice. But there is something not 
that clear in the documentation of Django, and how to make usage of 
namespace, in a consistent way. Lets take it by example.

I'm using this pretty amazing app "greeter" that was written by a superuser 
from a country far away from my own. It is a pretty simple app, that has 
two url mappings:

url(r'^list/$', HelloWorldList.as_view(), name='list'),
url(r'^greet/(?P\d+)/$', HelloWorldGreet.as_view(), name='greet'),


The template of HelloWorldList view is using the template tag url like this: {% 
url 'greet' greeter.pk %}.

After that I hook up the application in my project by including it in my 
project urls.py:

url(r'^greeter/', include('greeter.urls')),


Everything works well, I felt like a Django guru integrating the hello 
world app to my own project. I can access /greeter/list and clicking on the 
greetings works well.

Later that night I go to bed, feeling confident, kissing my wife goodnight 
with a smile on my face. I wake up warm, sweaty, with my heart beating. I 
run to my laptop, just realized I forgot to namespace the greet app, 
because I just realized I am using the list name in another place in my 
project, and I don't have any automated tests, so I better namespace it 
quickly.

So, I change my project url mapping to this:

url(r'^greeter/', include('greeter.urls', namespace='greeter')),


Boom crash. Visiting the /greeter/list/ page gives me:


Reverse for 'greet' with arguments '()' and keyword arguments '{pk:1}' not 
found. 0 pattern(s) tried: []


I start to doubt the author of the 'greeter' app, that he didn't prepare his 
app for being used in other projects, where the project might need namespacing 
to avoid conflicts.


Digging into Django documentation, I don't really find any argument for the 
author of the 'greeter' app to be sloppy and not caring of details.


Someone who can enlighten me why django doesn't try to default to the current 
app when resolving namespaces? Or can someone enlighten me how I can help out 
the author of the 'greeting' app, so it really is reusable in other projects?

-- 
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/4106d7ca-06aa-4d5e-8094-4370f116a167%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database field for Image Upload

[pjotr]

https://docs.djangoproject.com/en/1.7/ref/models/fields/#imagefield

The image file will not be stored in the database, but in MEDIAROOT by 
default. So maybe this is not the answer to your question.

On Wednesday, October 29, 2014 10:18:30 AM UTC+1, Shubham Gupta wrote:
>
> Is there  any way from which i can add image  as a field so that images 
> are added into my database?
> what data type i must use for this problem..?
> thank you 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/b8612d81-a510-43d7-bc7f-57d81b76d686%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jump on 1.7 in new project or stick to 1.6, target release date 30th of September

[pjotr]

We are starting a new project and 1.7 is not far away according to 
information provided in the release plan etc. Do we "dare" to jump on 1.7 
already now or should we be super careful and stick to 1.6? My intuition 
says 1.7 :) 

-- 
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/50678ae0-65ce-4325-82e2-f1bbd2e3d376%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.