Re: beginner . problem simple form.

[Jordi Fernandez]

console no message, I see  in one second what form search in bad url , bad 
because I want to the same view.(url)  It's search 
in http://127.0.0.1:8000/crearasistenciaclasse/crearasistenciaclasse
 this  is incorrect the correct 
is http://127.0.0.1:8000/crearasistenciaclasse



El diumenge, 21 agost de 2016 15:41:07 UTC+2, ludovic coues va escriure:
>
> Do you have any message in the console where you run "python manage.py 
> runserver" ? 
>
> 2016-08-21 12:16 GMT+02:00 Jordi Fernandez <fernand...@gmail.com 
> >: 
> > hi, 
> > 
> > I have my firts application django it's fine. . But! I have a problem 
> with a 
> > simple form. I  think this  is a problem the my experience of all entorn 
> ( 
> > html, form action, ..) 
> > 
> > the problem is when a submit my form is a eror -> ERROR LOADING PAGE 
> > 
> > if I test my script I not received a method post. why? 
> > 
> > 
> > 
> > thank you 
> > 
> > 
> > This is my template form 
> > 
> > {% csrf_token %} 
> > {{ form.name.errors }} 
> >  
> > 
> > {{form.as_p}} 
> > 
> >  
> >  
> > 
> >  
> > 
> > 
> > this is my wiew 
> > 
> > def crearasistenciaclasse(request): 
> > #return HttpResponse('ok') 
> > 
> > if request.method == "POST": 
> > form = CrearasistenciaclasseForm(request.POST) 
> > if form.is_valid(): 
> >Asistencia = form.save() 
> >return redirect('dojo.views.reportaralumnos') 
> > else: 
> > user = 6 
> > form = CrearasistenciaclasseForm(my_arg=user) 
> > 
> > return render_to_response('asistencias/crearasistenciaclasse.html', 
> > {'form': form}) 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > this is my form 
> > 
> > class CrearasistenciaclasseForm(forms.Form): 
> > alumnos = forms.ModelChoiceField(queryset=Alumno.objects.all()) 
> > classesobertes = 
> > forms.ModelChoiceField(queryset=Classe.objects.filter(estado='A')) 
> > def __init__(self, *args, **kwargs): 
> > my_arg = kwargs.pop('my_arg') 
> > super(CrearasistenciaclasseForm, self).__init__(*args, **kwargs) 
> > 
> > self.fields['classesobertes'].label = "Classe" 
> > 
> > self.fields['alumnos'].initial = my_arg 
> > 
> > -- 
> > 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 https://groups.google.com/group/django-users. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-users/71bb6ab8-e14a-47aa-91ad-57d4ac29e6f0%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
>
> Cordialement, Coues Ludovic 
> +336 148 743 42 
>

-- 
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/4cbcd76a-1d38-45cd-8680-438cde64ad17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: beginner . problem simple form.

[Jordi Fernandez]

the second is a comment

El dimarts, 30 agost de 2016 18:56:39 UTC+2, Jordi Fernandez va escriure:
>
>
> yes  , we are test
> El dilluns, 22 agost de 2016 22:38:39 UTC+2, ludovic coues va escriure:
>>
>> The second form tag is in an html comment. Everything inside  
>> won't be rendered. 
>>
>> 2016-08-22 14:31 GMT+02:00 Vijay Khemlani <vkhe...@gmail.com>: 
>> > Also, why do you have two form tags in your html? 
>> > 
>> > On Sun, Aug 21, 2016 at 10:40 AM, ludovic coues <cou...@gmail.com> 
>> wrote: 
>> >> 
>> >> Do you have any message in the console where you run "python manage.py 
>> >> runserver" ? 
>> >> 
>> >> 2016-08-21 12:16 GMT+02:00 Jordi Fernandez <fernand...@gmail.com>: 
>> >> > hi, 
>> >> > 
>> >> > I have my firts application django it's fine. . But! I have a 
>> problem 
>> >> > with a 
>> >> > simple form. I  think this  is a problem the my experience of all 
>> entorn 
>> >> > ( 
>> >> > html, form action, ..) 
>> >> > 
>> >> > the problem is when a submit my form is a eror -> ERROR LOADING PAGE 
>> >> > 
>> >> > if I test my script I not received a method post. why? 
>> >> > 
>> >> > 
>> >> > 
>> >> > thank you 
>> >> > 
>> >> > 
>> >> > This is my template form 
>> >> > 
>> >> > {% csrf_token 
>> %} 
>> >> > {{ form.name.errors }} 
>> >> >  
>> >> > 
>> >> > {{form.as_p}} 
>> >> > 
>> >> >  
>> >> >  
>> >> > 
>> >> >  
>> >> > 
>> >> > 
>> >> > this is my wiew 
>> >> > 
>> >> > def crearasistenciaclasse(request): 
>> >> > #return HttpResponse('ok') 
>> >> > 
>> >> > if request.method == "POST": 
>> >> > form = CrearasistenciaclasseForm(request.POST) 
>> >> > if form.is_valid(): 
>> >> >Asistencia = form.save() 
>> >> >return redirect('dojo.views.reportaralumnos') 
>> >> > else: 
>> >> > user = 6 
>> >> > form = CrearasistenciaclasseForm(my_arg=user) 
>> >> > 
>> >> > return 
>> render_to_response('asistencias/crearasistenciaclasse.html', 
>> >> > {'form': form}) 
>> >> > 
>> >> > 
>> >> > 
>> >> > 
>> >> > 
>> >> > 
>> >> > 
>> >> > 
>> >> > 
>> >> > this is my form 
>> >> > 
>> >> > class CrearasistenciaclasseForm(forms.Form): 
>> >> > alumnos = forms.ModelChoiceField(queryset=Alumno.objects.all()) 
>> >> > classesobertes = 
>> >> > forms.ModelChoiceField(queryset=Classe.objects.filter(estado='A')) 
>> >> > def __init__(self, *args, **kwargs): 
>> >> > my_arg = kwargs.pop('my_arg') 
>> >> > super(CrearasistenciaclasseForm, self).__init__(*args, **kwargs) 
>> >> > 
>> >> > self.fields['classesobertes'].label = "Classe" 
>> >> > 
>> >> > self.fields['alumnos'].initial = my_arg 
>> >> > 
>> >> > -- 
>> >> > 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 https://groups.google.com/group/django-users. 
>> >> > To view this discussion on the web visit 
>> >> > 
>> >> > 
>> https://groups.google.com/d/msgid/django-users/71bb6ab8-e14a-47aa-91ad-57d4ac29e6f0%40googlegroups.com.
>>  
>>
>> >> > For more options, visit https://groups.google.com/d/optout. 
>> >> 
>> >> 
>> >> 
>> >> -- 
>> >> 
>> >> Cordialement, Coues Ludovic 
>> >> +336 148 743 42 
>> >> 
>

Re: beginner . problem simple form.

[Jordi Fernandez]

yes  , we are test
El dilluns, 22 agost de 2016 22:38:39 UTC+2, ludovic coues va escriure:
>
> The second form tag is in an html comment. Everything inside  
> won't be rendered. 
>
> 2016-08-22 14:31 GMT+02:00 Vijay Khemlani <vkhe...@gmail.com >: 
>
> > Also, why do you have two form tags in your html? 
> > 
> > On Sun, Aug 21, 2016 at 10:40 AM, ludovic coues <cou...@gmail.com 
> > wrote: 
> >> 
> >> Do you have any message in the console where you run "python manage.py 
> >> runserver" ? 
> >> 
> >> 2016-08-21 12:16 GMT+02:00 Jordi Fernandez <fernand...@gmail.com 
> >: 
> >> > hi, 
> >> > 
> >> > I have my firts application django it's fine. . But! I have a problem 
> >> > with a 
> >> > simple form. I  think this  is a problem the my experience of all 
> entorn 
> >> > ( 
> >> > html, form action, ..) 
> >> > 
> >> > the problem is when a submit my form is a eror -> ERROR LOADING PAGE 
> >> > 
> >> > if I test my script I not received a method post. why? 
> >> > 
> >> > 
> >> > 
> >> > thank you 
> >> > 
> >> > 
> >> > This is my template form 
> >> > 
> >> > {% csrf_token 
> %} 
> >> > {{ form.name.errors }} 
> >> >  
> >> > 
> >> > {{form.as_p}} 
> >> > 
> >> >  
> >> >  
> >> > 
> >> >  
> >> > 
> >> > 
> >> > this is my wiew 
> >> > 
> >> > def crearasistenciaclasse(request): 
> >> > #return HttpResponse('ok') 
> >> > 
> >> > if request.method == "POST": 
> >> > form = CrearasistenciaclasseForm(request.POST) 
> >> > if form.is_valid(): 
> >> >Asistencia = form.save() 
> >> >return redirect('dojo.views.reportaralumnos') 
> >> > else: 
> >> > user = 6 
> >> > form = CrearasistenciaclasseForm(my_arg=user) 
> >> > 
> >> > return 
> render_to_response('asistencias/crearasistenciaclasse.html', 
> >> > {'form': form}) 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > this is my form 
> >> > 
> >> > class CrearasistenciaclasseForm(forms.Form): 
> >> > alumnos = forms.ModelChoiceField(queryset=Alumno.objects.all()) 
> >> > classesobertes = 
> >> > forms.ModelChoiceField(queryset=Classe.objects.filter(estado='A')) 
> >> > def __init__(self, *args, **kwargs): 
> >> > my_arg = kwargs.pop('my_arg') 
> >> > super(CrearasistenciaclasseForm, self).__init__(*args, **kwargs) 
> >> > 
> >> > self.fields['classesobertes'].label = "Classe" 
> >> > 
> >> > self.fields['alumnos'].initial = my_arg 
> >> > 
> >> > -- 
> >> > 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 https://groups.google.com/group/django-users. 
> >> > To view this discussion on the web visit 
> >> > 
> >> > 
> https://groups.google.com/d/msgid/django-users/71bb6ab8-e14a-47aa-91ad-57d4ac29e6f0%40googlegroups.com.
>  
>
> >> > For more options, visit https://groups.google.com/d/optout. 
> >> 
> >> 
> >> 
> >> -- 
> >> 
> >> Cordialement, Coues Ludovic 
> >> +336 148 743 42 
> >> 
> >> -- 
> >> 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 https://groups.google.com/group/django-users. 
> >> To view this discussion on the web visit 
> >> 
> htt

Re: simple form, beginner

[Jordi Fernandez]

sorry a error es undefined and other is error loading page  (jquery)

El dimarts, 30 agost de 2016 17:44:00 UTC+2, Jordi Fernandez va escriure:
>
>
>  {% 
> csrf_token %}
>
>
>
>  {% csrf_token 
> %}
>
>
> the two instrucctions not working, my view not received nothing  post i 
> want a form with the same view.
>
> remember I am Beginner!
>
> thank you
>
>
> def crearasistenciaclasse(request):
> user = 6
> form = CrearasistenciaclasseForm(my_arg=user)
> if request.method == 'POST' :
>return HttpResponse('ok')
>form = CrearasistenciaclasseForm(request.POST)
>if form.is_valid():
>crearasistenciaclasse = Crearasistenciaclasse 
> (alumno=form_cleaned_data[alumnos],
>   
> classe=form_cleaned_data[classesobertes])
>crearasistenciaclasse.save()
>return redirect('dojo.views.reportaralumnos')
> else:
>#assert False, locals()
>user = 6
>form = CrearasistenciaclasseForm(my_arg=user)
>
>   
> return render_to_response('asistencias/crearasistenciaclasse.html', 
> {'form': form},
>  context_instance=RequestContext(request))
>
>
>
>
>
>

-- 
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/fc3437d7-8254-46b1-8c6a-6760041ec030%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

simple form, beginner

[Jordi Fernandez]

 {% csrf_token 
%}



 {% csrf_token 
%}


the two instrucctions not working, my view not received nothing  post i 
want a form with the same view.

remember I am Beginner!

thank you


def crearasistenciaclasse(request):
user = 6
form = CrearasistenciaclasseForm(my_arg=user)
if request.method == 'POST' :
   return HttpResponse('ok')
   form = CrearasistenciaclasseForm(request.POST)
   if form.is_valid():
   crearasistenciaclasse = Crearasistenciaclasse 
(alumno=form_cleaned_data[alumnos],
  
classe=form_cleaned_data[classesobertes])
   crearasistenciaclasse.save()
   return redirect('dojo.views.reportaralumnos')
else:
   #assert False, locals()
   user = 6
   form = CrearasistenciaclasseForm(my_arg=user)
   
  
return render_to_response('asistencias/crearasistenciaclasse.html', 
{'form': form},
 context_instance=RequestContext(request))





-- 
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/af425b7a-a8cf-41b6-88c9-5ffcc3d3fb19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

beginner . problem simple form.

[Jordi Fernandez]

hi,

I have my firts application django it's fine. . But! I have a problem with 
a simple form. I  think this  is a problem the my experience of all entorn 
( html, form action, ..)

the problem is when a submit my form is a eror -> ERROR LOADING PAGE

if I test my script I not received a method post. why?



thank you


*This is my template form*

{% csrf_token %}
{{ form.name.errors }}


{{form.as_p}}



 



*this is my wiew*

def crearasistenciaclasse(request):
#return HttpResponse('ok')
   
if request.method == "POST":
form = CrearasistenciaclasseForm(request.POST)
if form.is_valid():
   Asistencia = form.save()
   return redirect('dojo.views.reportaralumnos')
else:
user = 6
form = CrearasistenciaclasseForm(my_arg=user)

return render_to_response('asistencias/crearasistenciaclasse.html', 
{'form': form})









this is my form

class CrearasistenciaclasseForm(forms.Form):
alumnos = forms.ModelChoiceField(queryset=Alumno.objects.all())
classesobertes = 
forms.ModelChoiceField(queryset=Classe.objects.filter(estado='A'))
def __init__(self, *args, **kwargs):
my_arg = kwargs.pop('my_arg')
super(CrearasistenciaclasseForm, self).__init__(*args, **kwargs)

self.fields['classesobertes'].label = "Classe"

self.fields['alumnos'].initial = my_arg

-- 
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/71bb6ab8-e14a-47aa-91ad-57d4ac29e6f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Persistent DB connections and WSGI

[Jordi]

Hi,

Can I take for granted that connections between the DB and Django get 
closed when threads get killed?
I take my max_connections in postgres to be the amount of WSGI threads + 
some safety margin, and put use Django
in persistent DB connection mode (CONN_MAX_AGE = None) to avoid the 
overhead of re-establishing connections, but then if for some
reason threads get killed abrubtly by WSGI and restarted, I may run out 
of max_connections if they didn't get closed properly?

Or is this not a concern?

Thanks
Jordi

--
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/5679D6CB.50200%40promani.be.
For more options, visit https://groups.google.com/d/optout.

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

[jordi . gutierrez . hermoso]

On Wednesday, October 7, 2015 at 10:16:30 AM UTC-4, Carl Meyer wrote:
>
> You should be aware, though, that specifically in the case of the 
> django.contrib app tests, we make no promise that they will pass under 
> your project's configuration, 
>

That's fine. I just want to make sure *we *didn't break anything. 

-- 
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/483b06bc-b3ca-41ea-9228-7395bee7db9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

[jordi . gutierrez . hermoso]

Okay, I'll try grabbing the old test runner from git, thanks.

On Wednesday, October 7, 2015 at 8:38:40 AM UTC-4, Tim Graham wrote:
>
> Copying the old test runner from an old version of Django seems like a 
> fine solution. I thought someone might have published it on PyPI, but I 
> couldn't find it if so.
>
> On Wednesday, October 7, 2015 at 2:06:08 AM UTC-4, Gergely Polonkai wrote:
>>
>> I'm not sure I understand what you want to achieve. I use 1.8 and it runs 
>> all tests for all apps without backporting anything.
>> On 6 Oct 2015 22:39,  wrote:
>>
>>> I want the old behaviour of running all tests in INSTALLED_APPS by 
>>> default Actually, I don't care too much if this is accomplished by 
>>> grabbing the old django.test.simple.DjangoTestSuiteRunner from git history 
>>> or by any other means.
>>>
>>> On Tuesday, October 6, 2015 at 4:24:00 PM UTC-4, Gergely Polonkai wrote:

 Hello,

 do you mean the integrated unittest module, or the Django test runners?

 However, both needs to be fetched from old history, and I daresay it 
 won't be an easy fetch. 1.6 code will more than likely be incompatible 
 with 
 1.8, so even if you backmerge it, you will have to do a lot of patching.

 Best,
 Gergely
 On 6 Oct 2015 21:02,  wrote:

> Hey, sorry to respond to such an old thread, but now that 1.8 
> completely removed the old test runner, I am wondering if there's any way 
> to get it back.
>
> I don't want to explain why I want it back. Please don't tell me I 
> don't want it.
>
> So, starting from the axiom that I want it back, how should I do it? 
> Grab it from git history?
>
> On Tuesday, November 12, 2013 at 8:29:14 PM UTC-5, Russell Keith-Magee 
> wrote:
>>
>>
>> On Sun, Nov 10, 2013 at 3:36 PM, Kyle MacFarlane <
>> kylemac...@gmail.com> wrote:
>>
>>> With the new test runner in 1.6 it only seems to be running tests 
>>> under my project and ignoring all tests in dependent apps listed in 
>>> INSTALLED_APPS.
>>>
>>> If I try to specify another app to test by doing something like 
>>> "django test a_dependency" I get an exception from Python's unittest 
>>> saying 
>>> "Path must be within the project" (all my dependencies are installed 
>>> system 
>>> wide or in a shared buildout folder in my user dir).
>>>
>>> The only tests outside of my project I seem to be able to run are 
>>> Django's itself via "django test django".
>>>
>>> How can I get the new test runner to discover and run all tests in 
>>> INSTALLED_APPS? As far as I can tell the new test runner only supports 
>>> tests located under the cwd which is not very useful for me since my 
>>> projects tend to just amalgamate smaller apps located elsewhere.
>>>
>>
>> Hi Kyle,
>>
>> The short answer is no, you can't. However, there's method in this 
>> madness.
>>
>> Essentially *all* Django projects are amalgams of smaller apps from 
>> elsewhere, so you're not alone in this. However, it doesn't follow that 
>> you 
>> need to run the tests for those apps. Consider the tests for one of the 
>> many apps in your project. This app is either:
>>
>> 1) A standalone, third party app, provided by another developer. This 
>> developer has presumably written and run the test suite for that app, 
>> validated that they pass, and packaged the app as version X. You pin 
>> version X in your requirements file. At this point, there's no value in 
>> you 
>> running these tests as part of your own project -- these tests aren't 
>> going 
>> to start spontaneously failing just because they're in your project.
>>
>> 2) A standalone app that you're maintaining in house. Although you're 
>> maintaining this in house, it's really no different to case 1. Good 
>> discipline means writing code, running tests, and validating a release 
>> (either as a tagged version, or just a VCS hash/revision) and pinning at 
>> that release. Again, the testing of the app is (or should be) 
>> independent 
>> of the testing of your project.
>>
>> 3) An app that is strongly tied to this particular project. In which 
>> case, it should be part of the project directory, and will be picked up 
>> using Django's test suite. If you want to put your project directory 
>> somewhere other than the default, you can use the -t option to 
>> ./manage.py 
>> test to point at your top level project directory. This doesn't change 
>> the 
>> discovery strategy; it just alters the place that Django looks.
>>
>> So - you shouldn't have any need to run *all* the tests in 
>> INSTALLED_APPS -- just the apps that are actually part of your project, 
>> and 
>> won't be independently 

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

[jordi . gutierrez . hermoso]

No, the new test runner does not run any 3rd party apps not in my project, 
and it does not run django.contrib either.

On Wednesday, October 7, 2015 at 2:06:08 AM UTC-4, Gergely Polonkai wrote:
>
> I'm not sure I understand what you want to achieve. I use 1.8 and it runs 
> all tests for all apps without backporting anything.
> On 6 Oct 2015 22:39,  wrote:
>
>> I want the old behaviour of running all tests in INSTALLED_APPS by default 
>> Actually, 
>> I don't care too much if this is accomplished by grabbing the old 
>> django.test.simple.DjangoTestSuiteRunner from git history or by any other 
>> means.
>>
>> On Tuesday, October 6, 2015 at 4:24:00 PM UTC-4, Gergely Polonkai wrote:
>>>
>>> Hello,
>>>
>>> do you mean the integrated unittest module, or the Django test runners?
>>>
>>> However, both needs to be fetched from old history, and I daresay it 
>>> won't be an easy fetch. 1.6 code will more than likely be incompatible with 
>>> 1.8, so even if you backmerge it, you will have to do a lot of patching.
>>>
>>> Best,
>>> Gergely
>>> On 6 Oct 2015 21:02,  wrote:
>>>
 Hey, sorry to respond to such an old thread, but now that 1.8 
 completely removed the old test runner, I am wondering if there's any way 
 to get it back.

 I don't want to explain why I want it back. Please don't tell me I 
 don't want it.

 So, starting from the axiom that I want it back, how should I do it? 
 Grab it from git history?

 On Tuesday, November 12, 2013 at 8:29:14 PM UTC-5, Russell Keith-Magee 
 wrote:
>
>
> On Sun, Nov 10, 2013 at 3:36 PM, Kyle MacFarlane  > wrote:
>
>> With the new test runner in 1.6 it only seems to be running tests 
>> under my project and ignoring all tests in dependent apps listed in 
>> INSTALLED_APPS.
>>
>> If I try to specify another app to test by doing something like 
>> "django test a_dependency" I get an exception from Python's unittest 
>> saying 
>> "Path must be within the project" (all my dependencies are installed 
>> system 
>> wide or in a shared buildout folder in my user dir).
>>
>> The only tests outside of my project I seem to be able to run are 
>> Django's itself via "django test django".
>>
>> How can I get the new test runner to discover and run all tests in 
>> INSTALLED_APPS? As far as I can tell the new test runner only supports 
>> tests located under the cwd which is not very useful for me since my 
>> projects tend to just amalgamate smaller apps located elsewhere.
>>
>
> Hi Kyle,
>
> The short answer is no, you can't. However, there's method in this 
> madness.
>
> Essentially *all* Django projects are amalgams of smaller apps from 
> elsewhere, so you're not alone in this. However, it doesn't follow that 
> you 
> need to run the tests for those apps. Consider the tests for one of the 
> many apps in your project. This app is either:
>
> 1) A standalone, third party app, provided by another developer. This 
> developer has presumably written and run the test suite for that app, 
> validated that they pass, and packaged the app as version X. You pin 
> version X in your requirements file. At this point, there's no value in 
> you 
> running these tests as part of your own project -- these tests aren't 
> going 
> to start spontaneously failing just because they're in your project.
>
> 2) A standalone app that you're maintaining in house. Although you're 
> maintaining this in house, it's really no different to case 1. Good 
> discipline means writing code, running tests, and validating a release 
> (either as a tagged version, or just a VCS hash/revision) and pinning at 
> that release. Again, the testing of the app is (or should be) independent 
> of the testing of your project.
>
> 3) An app that is strongly tied to this particular project. In which 
> case, it should be part of the project directory, and will be picked up 
> using Django's test suite. If you want to put your project directory 
> somewhere other than the default, you can use the -t option to 
> ./manage.py 
> test to point at your top level project directory. This doesn't change 
> the 
> discovery strategy; it just alters the place that Django looks.
>
> So - you shouldn't have any need to run *all* the tests in 
> INSTALLED_APPS -- just the apps that are actually part of your project, 
> and 
> won't be independently tested. If the app is independently maintained, 
> but 
> not independently tested, you've got much bigger problems :-)
>
> Yours,
> Russ Magee %-)
>
 -- 
 You received this message because you are subscribed to the Google 
 Groups "Django users" group.
 To 

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

[jordi . gutierrez . hermoso]

I want the old behaviour of running all tests in INSTALLED_APPS by default 
Actually, 
I don't care too much if this is accomplished by grabbing the old 
django.test.simple.DjangoTestSuiteRunner from git history or by any other 
means.

On Tuesday, October 6, 2015 at 4:24:00 PM UTC-4, Gergely Polonkai wrote:
>
> Hello,
>
> do you mean the integrated unittest module, or the Django test runners?
>
> However, both needs to be fetched from old history, and I daresay it won't 
> be an easy fetch. 1.6 code will more than likely be incompatible with 1.8, 
> so even if you backmerge it, you will have to do a lot of patching.
>
> Best,
> Gergely
> On 6 Oct 2015 21:02,  wrote:
>
>> Hey, sorry to respond to such an old thread, but now that 1.8 completely 
>> removed the old test runner, I am wondering if there's any way to get it 
>> back.
>>
>> I don't want to explain why I want it back. Please don't tell me I don't 
>> want it.
>>
>> So, starting from the axiom that I want it back, how should I do it? Grab 
>> it from git history?
>>
>> On Tuesday, November 12, 2013 at 8:29:14 PM UTC-5, Russell Keith-Magee 
>> wrote:
>>>
>>>
>>> On Sun, Nov 10, 2013 at 3:36 PM, Kyle MacFarlane  
>>> wrote:
>>>
 With the new test runner in 1.6 it only seems to be running tests under 
 my project and ignoring all tests in dependent apps listed in 
 INSTALLED_APPS.

 If I try to specify another app to test by doing something like "django 
 test a_dependency" I get an exception from Python's unittest saying "Path 
 must be within the project" (all my dependencies are installed system wide 
 or in a shared buildout folder in my user dir).

 The only tests outside of my project I seem to be able to run are 
 Django's itself via "django test django".

 How can I get the new test runner to discover and run all tests in 
 INSTALLED_APPS? As far as I can tell the new test runner only supports 
 tests located under the cwd which is not very useful for me since my 
 projects tend to just amalgamate smaller apps located elsewhere.

>>>
>>> Hi Kyle,
>>>
>>> The short answer is no, you can't. However, there's method in this 
>>> madness.
>>>
>>> Essentially *all* Django projects are amalgams of smaller apps from 
>>> elsewhere, so you're not alone in this. However, it doesn't follow that you 
>>> need to run the tests for those apps. Consider the tests for one of the 
>>> many apps in your project. This app is either:
>>>
>>> 1) A standalone, third party app, provided by another developer. This 
>>> developer has presumably written and run the test suite for that app, 
>>> validated that they pass, and packaged the app as version X. You pin 
>>> version X in your requirements file. At this point, there's no value in you 
>>> running these tests as part of your own project -- these tests aren't going 
>>> to start spontaneously failing just because they're in your project.
>>>
>>> 2) A standalone app that you're maintaining in house. Although you're 
>>> maintaining this in house, it's really no different to case 1. Good 
>>> discipline means writing code, running tests, and validating a release 
>>> (either as a tagged version, or just a VCS hash/revision) and pinning at 
>>> that release. Again, the testing of the app is (or should be) independent 
>>> of the testing of your project.
>>>
>>> 3) An app that is strongly tied to this particular project. In which 
>>> case, it should be part of the project directory, and will be picked up 
>>> using Django's test suite. If you want to put your project directory 
>>> somewhere other than the default, you can use the -t option to ./manage.py 
>>> test to point at your top level project directory. This doesn't change the 
>>> discovery strategy; it just alters the place that Django looks.
>>>
>>> So - you shouldn't have any need to run *all* the tests in 
>>> INSTALLED_APPS -- just the apps that are actually part of your project, and 
>>> won't be independently tested. If the app is independently maintained, but 
>>> not independently tested, you've got much bigger problems :-)
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>> -- 
>> 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/df0a8e3c-129e-4db4-8e8a-12d6d6ce7573%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message 

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

[jordi . gutierrez . hermoso]

Hey, sorry to respond to such an old thread, but now that 1.8 completely 
removed the old test runner, I am wondering if there's any way to get it 
back.

I don't want to explain why I want it back. Please don't tell me I don't 
want it.

So, starting from the axiom that I want it back, how should I do it? Grab 
it from git history?

On Tuesday, November 12, 2013 at 8:29:14 PM UTC-5, Russell Keith-Magee 
wrote:
>
>
> On Sun, Nov 10, 2013 at 3:36 PM, Kyle MacFarlane  > wrote:
>
>> With the new test runner in 1.6 it only seems to be running tests under 
>> my project and ignoring all tests in dependent apps listed in 
>> INSTALLED_APPS.
>>
>> If I try to specify another app to test by doing something like "django 
>> test a_dependency" I get an exception from Python's unittest saying "Path 
>> must be within the project" (all my dependencies are installed system wide 
>> or in a shared buildout folder in my user dir).
>>
>> The only tests outside of my project I seem to be able to run are 
>> Django's itself via "django test django".
>>
>> How can I get the new test runner to discover and run all tests in 
>> INSTALLED_APPS? As far as I can tell the new test runner only supports 
>> tests located under the cwd which is not very useful for me since my 
>> projects tend to just amalgamate smaller apps located elsewhere.
>>
>
> Hi Kyle,
>
> The short answer is no, you can't. However, there's method in this madness.
>
> Essentially *all* Django projects are amalgams of smaller apps from 
> elsewhere, so you're not alone in this. However, it doesn't follow that you 
> need to run the tests for those apps. Consider the tests for one of the 
> many apps in your project. This app is either:
>
> 1) A standalone, third party app, provided by another developer. This 
> developer has presumably written and run the test suite for that app, 
> validated that they pass, and packaged the app as version X. You pin 
> version X in your requirements file. At this point, there's no value in you 
> running these tests as part of your own project -- these tests aren't going 
> to start spontaneously failing just because they're in your project.
>
> 2) A standalone app that you're maintaining in house. Although you're 
> maintaining this in house, it's really no different to case 1. Good 
> discipline means writing code, running tests, and validating a release 
> (either as a tagged version, or just a VCS hash/revision) and pinning at 
> that release. Again, the testing of the app is (or should be) independent 
> of the testing of your project.
>
> 3) An app that is strongly tied to this particular project. In which case, 
> it should be part of the project directory, and will be picked up using 
> Django's test suite. If you want to put your project directory somewhere 
> other than the default, you can use the -t option to ./manage.py test to 
> point at your top level project directory. This doesn't change the 
> discovery strategy; it just alters the place that Django looks.
>
> So - you shouldn't have any need to run *all* the tests in INSTALLED_APPS 
> -- just the apps that are actually part of your project, and won't be 
> independently tested. If the app is independently maintained, but not 
> independently tested, you've got much bigger problems :-)
>
> Yours,
> Russ Magee %-)
>

-- 
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/df0a8e3c-129e-4db4-8e8a-12d6d6ce7573%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Models.clean() how to raise ValidationError WITH error_code and show field_based errors in the Form-Template?

[jordi collell]

An easy way is to test that the rendered form has the error message raised 
suring rhe validation.

-- 
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/eef3dbd2-f0ba-4c4c-8eef-af2aee8befe4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Restricting CreateView

[jordi collell]

I think you don't need extra packages for the task. You can overwrite the 
dispatch to validate permissions on get and post create view.

-- 
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/5af601d2-b5cb-422c-ad1c-7ea45a5b8a20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

BaseListView's get_context_data is missing kwargs?

[jordi collell]

Not sure if i'm understanding what are you saying. But kwargs on get.. Are 
stored on a object property. Self.kwargs (prior the dispatch) method.

-- 
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/1956c0d6-42ff-49c8-bb01-54380b09fdae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

BaseListView's get_context_data is missing kwargs?

[jordi collell]

Not sure if i'm understanding what are you saying. But kwargs on get.. Are 
stored on a object property. Self.kwargs (prior the dispatch) method.

-- 
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/5375c024-ee41-4b46-816d-e63fadb4a720%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DB Design question

[jordi collell]

Hi all!

I have to store spreadsheet info on a db. Some kind of quotes where the 
user can store distinct prices for every zone. 

After modeling the data, i have a Cell like row. (related to a zone, and 
with a quantity field).. something like:

zone1  1  100
zone1  2  99
zone1  3  98

Every zone is a fk... The problem is, that data grows quick.. because some 
quotes can have up to 65 unit fields with 70 to 100 zones.. 

Currently i have a autopk field. but I'm not sure if it will scale.. If i 
have 5000 users and every users makes 100 quotations.. (7000 rows on the 
worst case) this is 35.. easy enought to get out of autoincrement 
fields.. 

I'm thinking on getting rid of the pk field, and use a unique together with 
(zone_units). do you think this is a good aproach with the orm? I saw that 
is not possible to make primary key fields ( with grouped fields), but 
perhaps I can do it with instead of declaring a int field, have a char 
field storing the 
%s_%s_%s ( quote_id, zone_id, units ) ... 

do you think the last could be a good aproach? 

Sure if i have to shard the data (on the future) I can do it, using this 
kind of keys.. Data will be queryed by zone.. (For making comparasions of 
quotes)

I will apreciate any help on the matter.


-- 
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/c2a69c66-d1b8-4f08-95ed-b26fbb1d762e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GeometryCollectionField with MultiPolygon

[jordi]

I have a class with a GeometryCollectionField, when I try to save a
MultiPolygon object in the GeometryCollectionField I always get a NULL
value in the GeometryCollectionField.
Other types of objects saved in the GeometryCollectionField work fine.
Somebody knows whats happening?


from django.contrib.gis.db import models
class gcol(models.Model):
name = models.CharField(max_length=50)
geom = models.GeometryCollectionField()
objects = models.GeoManager()

from gcollection.models import gcol
from django.contrib.gis.geos import  GeometryCollection,
MultiPolygon,  Polygon

p1 = Polygon( ((0, 0), (0, 1), (1, 1), (0, 0)) )
p2 = Polygon( ((1, 1), (1, 2), (2, 2), (1, 1)) )
mp = MultiPolygon(p1,p2)

a=gcol.objects.get(name='a')
a.geom=GeometryCollection((p1, p2))
a.save()
a.geom=GeometryCollection(mp)
a.save()

/usr/lib64/python2.7/site-packages/django/db/backends/sqlite3/base.py
in execute(self, query, params)
198 query = self.convert_query(query)
199 try:
--> 200 return Database.Cursor.execute(self, query,
params)
201 except Database.IntegrityError, e:
202 raise utils.IntegrityError,
utils.IntegrityError(*tuple(e)), sys.exc_info()[2]

IntegrityError: gcollection_gcol.geom may not be NULL

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

index for fields with unique=True and db_index True

[jordi]

When I create the following model I get an index for field2 with syndb
or sqlindexes. Why doesn't it create an index for field3?

from django.db import models
class Entitat(models.Model):
field1 = models.CharField(max_length=4, unique=True)
field2 = models.CharField(max_length=4, db_index=True )
field3 = models.CharField(max_length=4, unique=True,
db_index=True )

To create an index for field3 I have to remove "unique=True", create
the index and after add again "unique=True", so django admin captures
non unique entries.

I am using sqlite (with spatialite).

I don't know if this is a bug, a feature or I understand something
wrong?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: making slug field unique

[Jordi Funollet]

Julio Nobrega dixit:
>  Afaik Django enforces uniqueness at the application level, but you
> could always add it to the database:

Ouch. Really? So Django is assuming that we are going to work with their
database *exclusively* through Django, and doesn't protect us from doing silly
things to the data when integrating with other applications.

This restriction should be on database, shouldn't it?

-- 
##
### Jordi Funollet
### http://www.terraquis.net