Don't save anything if error on save method

[elcaiaimar]

Hello,

I' ve an application where I upload a CSV file and save all its rows in a 
database. This is ok, but, at the moment, when I upload the file and it 
exists some error on it, it saves all rows until the wrong row. What I want 
to achieve is that if there is an error when I save, don't save anything. 
Is there any way to do that?

if formularioarchivomedios.is_valid():

   reader = csv.DictReader(request.FILES['docfile'], delimiter=',') 

   for row in reader:

try:
titulo=row['titulo']
url=row['url']

my_file = Medios(titulo=titulo, url=url)

my_file.save()



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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/908406c1-3f06-4889-953e-544a7a43afea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Don't save anything if error on save method

[Michal Petrucha]

On Tue, Apr 19, 2016 at 01:12:13AM -0700, elcaiaimar wrote:
> Hello,
> 
> I' ve an application where I upload a CSV file and save all its rows in a 
> database. This is ok, but, at the moment, when I upload the file and it 
> exists some error on it, it saves all rows until the wrong row. What I want 
> to achieve is that if there is an error when I save, don't save anything. 
> Is there any way to do that?
> 
> if formularioarchivomedios.is_valid():
> 
>reader = csv.DictReader(request.FILES['docfile'], delimiter=',') 
> 
>for row in reader:
> 
> try:
> titulo=row['titulo']
> url=row['url']
> 
> my_file = Medios(titulo=titulo, url=url)
> 
> my_file.save()
> 
> 
> 
> Thank you in advance!

This is exactly the purpose of database transactions. All you need to
do is to wrap the block of code in transaction.atomic(), like this::

from django.db import transaction

[...]

if formularioarchivomedios.is_valid():
reader = csv.DictReader(request.FILES['docfile'], delimiter=',') 
try:
with transaction.atomic():
for row in reader:
titulo = row['titulo']
url = row['url']

my_file = Medios(titulo=titulo, url=url)

my_file.save()

except WhateverErrorYouWantToHandle as e:
handle_error(e)

Just make sure to handle the error outside of the atomic block; that
way, the transaction will be automatically rolled back if an error
does happen. If you handle the error inside the atomic block, Django
will think there was no error, and it will happily try to commit the
transaction as if everything was all right.

Good luck,

Michal

-- 
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/20160419084755.GC1129%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

MTV and MVC difference

[Mukul Chakravarty]

What is the difference between Models in django MTV architecture and Models 
in rails MVC architecture ?

-- 
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/15c651fc-a3a3-4bd8-8e1a-30713597bda9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Possible bug in Django Admin site in tabular inline or stacked inline with datetime shortcuts

[Константин Попов]

Hi, django users.

I have found possible bug in django admin site, using tabular inline with 
datetime field. The same bug exists in stacked inline as I can see form 
code.

I am not sure what is the best way to report the bug, so I decided to write 
here first.
Please, give me advice on my next steps.

Now, about the bug.

Any datetime field is supplied with calendar and clock 
shortcuts. static/admin/js/admin/DateTimeShortcuts.js contains code, wich 
generated all html markup for them, this code runs on page load event.
This code makes both span class="datetimeshortcuts" and hidden div 
class="calendarbox module" or class="clockbox module".

TabularFormset and stackedFormset jquery plugins, that live 
in static/admin/js/inlines.js, both need to reinit datetime fields in the 
newly added formset rows.
They do it with this function:

var reinitDateTimeShortCuts = function() {

// Reinitialize the calendar and clock widgets by force, yuck.
if (typeof DateTimeShortcuts !== "undefined") {
$(".datetimeshortcuts").remove();
DateTimeShortcuts.init();
} 

};


As anyone can see, this function removes datetimeshortcuts spans but doesn't 
remove "calendarbox module" and clockbox module" divs.

Then, call to the DateTimeShortcuts.init() again and again adds both the spans 
and the divs for all datetime fields on the page.


Thus, by adding 20 rows in formset, I have about 400 useless hidden divs on my 
page.



I see several ways to fix this bug.


1. Modify DateTimeShortcuts.js to use single hidden div for all datetime fields 
on the page

2. Modify DateTimeShortcuts.js init function to check if the datetime field is 
alreay initialized to avoid it's re-initialization, and exclude removing any 
DOM elements from reinitDateTimeShortCuts 

3. Expand set of elements, removed in reinitDateTimeShortCuts and remove divs 
together with spans. Maybe it would be better to add reinit function into 
DateTimeShortcuts.js

-- 
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/1e8a2e42-64e7-4ccf-9932-ed97462e9ea1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Help with django.

[Григор Колев]

I try to learnind django.
But can't understand how to write good django code.
Can I write form in template or thear a good reson to use django form.
Or must I use class based view or function is the best idea.
How can get the django form from value if post method in class based viwe.

-- 
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/fa963d9f-43fa-4137-9653-53c17e8c8b19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help with django.

[Jani Tiainen]

Hi, you should start with tutorials,

Django official:

https://docs.djangoproject.com/en/1.8/intro/tutorial01/

Django Girls Tutorial:

http://tutorial.djangogirls.org/

And finally on my list is Marina Mele's tutorial:

http://www.marinamele.com/taskbuster-django-tutorial


On 19.04.2016 14:23, Григор Колев wrote:

I try to learnind django.
But can't understand how to write good django code.
Can I write form in template or thear a good reson to use django form.
Or must I use class based view or function is the best idea.
How can get the django form from value if post method in class based viwe.



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

Registration Redux sign up process

[Luca Brandi]

Hello
I installed this app for authentication and registration purposes.
I am wondering if there is a way to send activation link only after admin 
has verified  user can be registered or if a signal could be receive dby 
admin when someone registers before activating it.. Thnaks

-- 
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/59d3b789-aa1c-4a2e-9564-b1c997449aa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MTV and MVC difference

[Javier Guerra Giraldez]

On 19 April 2016 at 12:53, Mukul Chakravarty  wrote:
> What is the difference between Models in django MTV architecture and Models
> in rails MVC architecture ?


IMNSHO, mostly about the realization that "controller" (as defined in
the original, GUI-oriented formulation of MVC) doesn't have a place in
every web application.

In a very concrete sense, the best place for it is the framework
itself.  So that leaves us with just models and presentation.  But the
presentation is best split in a data-gathering function and a
non-turing-complete template; so now you have Models, Views and
Templates.

Note also that Django Views are typically much thinner than MVC views.

-- 
Javier

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

Global variable

['luca72' via Django users]

hello my view.py is like this:

from django.contrib import auth
from django.contrib.auth.decorators import login_required
from django.db import models
from django.core.files.storage import FileSystemStorage
#from django.core.servers.basehttp import FileWrapper
from django.contrib.auth import authenticate, login
from .forms import FormContatti
from django.core.mail import send_mail
from django.views.decorators.csrf import csrf_protect
global lenguage
language = 'it'



def first_page(request):
testo = [" ." , 'bb'] 
if language == 'it':
testo = testo[0]
else :
testo = testo[1]
return render(request,'polls/first_page.html',{'testo':testo,})

where language can be it or en, in the web page i have two flag where i 
have to place an https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/157f35f6-7f52-4451-ae68-0fb704b9e64b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No Downtime Code Releases

[Avraham Serour]

I don't think you would gain anything by separating your models to a
different repository, what are you trying to gain here?

if you put a maintenance page when doing migrations it won't matter if the
models are from a different package or not.

you could still run migrations on a live system, you just should take into
account that there could still be parts of the system using something is
not there yet/anymore

so you should break migrations into 2 whenever you are adding or removing
something.

when adding a model or field you should first run the migrations and only
after that deploy the new code using the new model/field

when removing something you should first stop using it and then migrate.

you could plan your deployment/releases and know in advance if you are
either adding or removing something and never add and remove in the same
release
meaning commit and deploy the model and only after that commit the code
using the new model

or you can checkout the code on the side and runs migrations using this
separate env, this way you could add a new model and use it in the same
commit.

for removing you can just do it backwards.


Avraham



On Tue, Apr 19, 2016 at 3:38 AM,  wrote:

> Hey,
>
> I have two issues I'm looking at solving at work, and I'm looking for a
> couple suggestions as to how other people have solved this.  The two things
> are:
>
> * scale out their django installation to allow for smaller releases (I'm
> thinking microservices, but it could also be internal django apps or who
> knows what else)
> * minimizing the impact of migrations during releases (aka we want to be
> able to release in the middle of the afternoon
>
> Currently we put up a maintenance page whenever we are doing database
> operations (aka migrations).  This seems like a recommended best practice.
>
> One way I was thinking about addressing this issue was to break all of our
> models out into a separate repo.  That way we'd only need to deploy
> migrations when the models themselves have deployed.  For code that needs
> the models, we could pip install the repo as an app and away we go.
> Likewise it seems like I could break up different parts of our app via a
> similar strategy.
>
> Does this seem viable?  How have other people solved this kind of problem?
>
> Thanks,
>
> -Ben
>
> --
> 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/e5fd0359-9e8b-4cce-b3e1-4880951a2a8e%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tLHi%2BcnsvxheusPSx1EeVdfAt-ntS%2BkDs5bbG0%2BFYc3hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: No Downtime Code Releases

[Fred Stluka]

  
  
Ben,

I minimize downtime as much as possible by doing things in 
advance like copying all of the new files to a staging area on 
the PROD system, automatically inserting PROD passwords, 
running collectstatic, dumping the DB in case of problems, 
etc.  Then, I put up the maintenance page, quickly rsync the 
new files into place, run migrations, and hide the maintenance
page.

We used to shoot for releases with no downtime by copying
the *.py files into place, and letting Django notice and re-load
the *.pyc files automatically, but we ran onto some strange 
issues sometimes.  Seems like Django continued to use some
of the cached *.pyc files for a while.

It's worked out better to always delete all *.pyc files before 
rsyncing the *.py files into place, and to always restart the 
Apache server just before hiding the maintenance page, so 
we're sure everything gets reloaded cleanly.

This has also been a good idea as we've added more caching:
- Template files
- Fully assembled pages
- DB data
- etc.

Hope this helps,
--Fred
  
  Fred Stluka -- mailto:f...@bristle.com --
  http://bristle.com/~fred/
  
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service!
  
  Open Source: Without walls and fences, we need no Windows or
  Gates.
  

On 4/19/16 12:12 PM, Avraham Serour
  wrote:


  I don't think you would gain anything by separating
your models to a different repository, what are you trying to
gain here?


if you put a maintenance page when doing migrations it
  won't matter if the models are from a different package or
  not.


you could still run migrations on a live system, you just
  should take into account that there could still be parts of
  the system using something is not there yet/anymore


so you should break migrations into 2 whenever you are
  adding or removing something.


when adding a model or field you should first run the
  migrations and only after that deploy the new code using the
  new model/field


when removing something you should first stop using it and
  then migrate.


you could plan your deployment/releases and know in advance
  if you are either adding or removing something and never add
  and remove in the same release
meaning commit and deploy the model and only after that
  commit the code using the new model


or you can checkout the code on the side and runs
  migrations using this separate env, this way you could add a
  new model and use it in the same commit.


for removing you can just do it backwards.




Avraham




  
  
On Tue, Apr 19, 2016 at 3:38 AM, 
  wrote:
  
Hey,
  
  I have two issues I'm looking at solving at work, and I'm
  looking for a couple suggestions as to how other people
  have solved this.  The two things are:
  
  * scale out their django installation to allow for smaller
  releases (I'm thinking microservices, but it could also be
  internal django apps or who knows what else)
  * minimizing the impact of migrations during releases (aka
  we want to be able to release in the middle of the
  afternoon
  
  Currently we put up a maintenance page whenever we are
  doing database operations (aka migrations).  This seems
  like a recommended best practice.
  
  One way I was thinking about addressing this issue was to
  break all of our models out into a separate repo.  That
  way we'd only need to deploy migrations when the models
  themselves have deployed.  For code that needs the models,
  we could pip install the repo as an app and away we go. 
  Likewise it seems like I could break up different parts of
  our app via a similar strategy.
  
  Does this seem viable?  How have other people solved this
  kind of problem?
  
  Thanks,
  
  -Ben

-- 
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...@g

Re: Global variable

[Gabriel Marcondes]

Ciao Luca,

Take a look at django's i18n [0], it will spare you a lot of work.

[0] https://docs.djangoproject.com/es/1.9/topics/i18n/

On Tue, Apr 19, 2016 at 11:27 AM, 'luca72' via Django users <
django-users@googlegroups.com> wrote:

> hello my view.py is like this:
>
> from django.contrib import auth
> from django.contrib.auth.decorators import login_required
> from django.db import models
> from django.core.files.storage import FileSystemStorage
> #from django.core.servers.basehttp import FileWrapper
> from django.contrib.auth import authenticate, login
> from .forms import FormContatti
> from django.core.mail import send_mail
> from django.views.decorators.csrf import csrf_protect
> global lenguage
> language = 'it'
>
>
>
> def first_page(request):
> testo = [" ." , 'bb']
> if language == 'it':
> testo = testo[0]
> else :
> testo = testo[1]
> return render(request,'polls/first_page.html',{'testo':testo,})
>
> where language can be it or en, in the web page i have two flag where i
> have to place an  language, because any view have the if statement to the global varible
> language
>
> Thanks for your help
>
> Luca
>
> --
> 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/157f35f6-7f52-4451-ae68-0fb704b9e64b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
---
Gabriel Marcondes
Engenheiro de Computação - UFSCar

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

Re: Help with django.

[Григор Колев]

)My question is bed.
I read docs of course.
In another's Python frameworks I must write all classes to be used more 
than one time.
I make Button and it's.
If I need a button just call this class

class MyChoiceField(forms.Form):
def __init__(self, foo_choices, *args, **kwargs):
super(MyChoiceField, self).__init__(*args, **kwargs)
self.fields['options'].choices = foo_choices
options = forms.ChoiceField(label=False, choices=(), widget=forms.
RadioSelect(), required=True)

class SubmitButtonWidget(forms.Widget):
def render(self, name, text, attrs=None):
return '%s' % 
(html.escape(name), html.escape(text))

class ButtonField(forms.Field):
def __init__(self, *args, **kwargs):
if not kwargs:
kwargs = {}
kwargs["widget"] = SubmitButtonWidget

super(ButtonField, self).__init__(*args, **kwargs)

def clean(self, value):
return value

class Button(forms.Form):
def __init__(self, initial, *args, **kwargs):
super(Button, self).__init__(*args, **kwargs)
self.fields['save'].initial = initial
save = ButtonField(label='', initial=())


# views
class Settings(View):
template_name = "settings.html"
def get(self, request):
if request.session['mod'] == True:
form = forms.SettingsForm(True, request.session['questionType'])
else:
form = forms.SettingsForm(False, request.session['questionType'
])

submit = forms.Button('Save')
return render(request, 'settings.html', {'form': form, 'submit':
submit})


def post(self, request):
if request.POST.get('mod'):
request.session['mod'] = True
else:
request.session['mod'] = False
if request.POST.get('choise'):
request.session['questionType'] = request.POST.get('choise')
redirect('/settings/')
return redirect('/')


class Game(View):
def get(self, request):
all_question = Questions.objects.filter(category=request.session[
'questionType']).values()
question = random.choice(all_question)
answers = candidate_answers(question, all_question, request.session[
'mod'])
if request.session['mod'] == True:
form = forms.MyChoiceField(answers)
button = forms.Button('Chek')
return render(request, 'quiz.html', {'question':question, 'form'
:form, 'button':button, 'answer':answers[0][1]})
else:
button = forms.YesNoButton() 
return render(request, 'quiz.html', {'question':question, 
'button':button, 'answer':answers[0]})

def post(self, request):
ok = request.POST.get('ok')
answer =  request.POST.get('options')
if request.session['mod'] == True:
if ok == answer:
answer = True
else:
answer = False
else:
if 'yes' in request.POST:
if ok == answer:
answer = True
else:
answer = False
else:
if ok != answer:
answer = True
else:
answer = False
return redirect('answer', answer = answer).py 

Is this a good django code, or i must 
or i must make form for every single form?
It is a good views or there a different way?


вторник, 19 април 2016 г., 15:45:55 UTC+3, Jani Tiainen написа:
>
> Hi, you should start with tutorials, 
>
> Django official: 
>
> https://docs.djangoproject.com/en/1.8/intro/tutorial01/ 
>
> Django Girls Tutorial: 
>
> http://tutorial.djangogirls.org/ 
>
> And finally on my list is Marina Mele's tutorial: 
>
> http://www.marinamele.com/taskbuster-django-tutorial 
>
>
> On 19.04.2016 14:23, Григор Колев wrote: 
> > I try to learnind django. 
> > But can't understand how to write good django code. 
> > Can I write form in template or thear a good reson to use django form. 
> > Or must I use class based view or function is the best idea. 
> > How can get the django form from value if post method in class based 
> viwe. 
> > 
> Въведете кода тук...
>
>
>
>

-- 
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/7b5ca163-5d1b-4a89-8185-3b107563d4f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help with django.

[Григор Колев]

I apologize for the mistakes, but function for insert a code is just 
terrible

-- 
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/e4a72fb2-b416-46dc-86da-2d7e8278004f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help with django.

[Григор Колев]

сряда, 20 април 2016 г., 0:00:06 UTC+3, Григор Колев написа:
>
> )My question is bed.
> I read docs of course.
> In another's Python frameworks I must write all classes to be used more 
> than one time.
> I make Button and it's.
> If I need a button just call this class
>
> class MyChoiceField(forms.Form):
> def __init__(self, foo_choices, *args, **kwargs):
> super(MyChoiceField, self).__init__(*args, **kwargs)
> self.fields['options'].choices = foo_choices
> options = forms.ChoiceField(label=False, choices=(), widget=forms.
> RadioSelect(), required=True)
>
> class SubmitButtonWidget(forms.Widget):
> def render(self, name, text, attrs=None):
> return '%s' 
> % (html.escape(name), html.escape(text))
>
> class ButtonField(forms.Field):
> def __init__(self, *args, **kwargs):
> if not kwargs:
> kwargs = {}
> kwargs["widget"] = SubmitButtonWidget
>
> super(ButtonField, self).__init__(*args, **kwargs)
>
> def clean(self, value):
> return value
>
> class Button(forms.Form):
> def __init__(self, initial, *args, **kwargs):
> super(Button, self).__init__(*args, **kwargs)
> self.fields['save'].initial = initial
> save = ButtonField(label='', initial=())
>
>
> # views.py
> class Settings(View):
> template_name = "settings.html"
> def get(self, request):
> if request.session['mod'] == True:
> form = forms.SettingsForm(True, request.session['questionType'
> ])
> else:
> form = forms.SettingsForm(False, request.session[
> 'questionType'])
> 
> submit = forms.Button('Save')
> return render(request, 'settings.html', {'form': form, 'submit':
> submit})
> 
> 
> def post(self, request):
> if request.POST.get('mod'):
> request.session['mod'] = True
> else:
> request.session['mod'] = False
> if request.POST.get('choise'):
> request.session['questionType'] = request.POST.get('choise')
> return redirect('/')
> 
>
> class Game(View):
> def get(self, request):
> all_question = Questions.objects.filter(category=request.session[
> 'questionType']).values()
> question = random.choice(all_question)
> answers = candidate_answers(question, all_question, request.
> session['mod'])
> if request.session['mod'] == True:
> form = forms.MyChoiceField(answers)
> button = forms.Button('Chek')
> return render(request, 'quiz.html', {'question':question, 
> 'form':form, 'button':button, 'answer':answers[0][1]})
> else:
> button = forms.YesNoButton() 
> return render(request, 'quiz.html', {'question':question, 
> 'button':button, 'answer':answers[0]})
> 
> def post(self, request):
> ok = request.POST.get('ok')
> answer =  request.POST.get('options')
> if request.session['mod'] == True:
> if ok == answer:
> answer = True
> else:
> answer = False
> else:
> if 'yes' in request.POST:
> if ok == answer:
> answer = True
> else:
> answer = False
> else:
> if ok != answer:
> answer = True
> else:
> answer = False
> return redirect('answer', answer = answer)
>
> Is this a good django code, or i must 
> make form class for every single form?
> It is a good views or there a different way?
>
>
> вторник, 19 април 2016 г., 15:45:55 UTC+3, Jani Tiainen написа:
>>
>> Hi, you should start with tutorials, 
>>
>> Django official: 
>>
>> https://docs.djangoproject.com/en/1.8/intro/tutorial01/ 
>>
>> Django Girls Tutorial: 
>>
>> http://tutorial.djangogirls.org/ 
>>
>> And finally on my list is Marina Mele's tutorial: 
>>
>> http://www.marinamele.com/taskbuster-django-tutorial 
>>
>>
>> On 19.04.2016 14:23, Григор Колев wrote: 
>> > I try to learnind django. 
>> > But can't understand how to write good django code. 
>> > Can I write form in template or thear a good reson to use django form. 
>> > Or must I use class based view or function is the best idea. 
>> > How can get the django form from value if post method in class based 
>> viwe. 
>> > 
>> Въведете кода тук...
>>
>>
>>
>>

-- 
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/15110dea-7677-49f1-b0d9-c027151d1abb%40googlegroups.com.
For more options, visit https://groups.google.

Re: No Downtime Code Releases

[Avraham Serour]

you can easily do code reloading with uwsgi graceful reload, no user will
ever know you reloaded your application, no need to juggle, I mean you
aren't using mod_wsgi or anything like that right?

On Tue, Apr 19, 2016 at 10:07 PM, Fred Stluka  wrote:

> Ben,
>
> I minimize downtime as much as possible by doing things in
> advance like copying all of the new files to a staging area on
> the PROD system, automatically inserting PROD passwords,
> running collectstatic, dumping the DB in case of problems,
> etc.  Then, I put up the maintenance page, quickly rsync the
> new files into place, run migrations, and hide the maintenance
> page.
>
> We used to shoot for releases with no downtime by copying
> the *.py files into place, and letting Django notice and re-load
> the *.pyc files automatically, but we ran onto some strange
> issues sometimes.  Seems like Django continued to use some
> of the cached *.pyc files for a while.
>
> It's worked out better to always delete all *.pyc files before
> rsyncing the *.py files into place, and to always restart the
> Apache server just before hiding the maintenance page, so
> we're sure everything gets reloaded cleanly.
>
> This has also been a good idea as we've added more caching:
> - Template files
> - Fully assembled pages
> - DB data
> - etc.
>
> Hope this helps,
> --Fred
> --
> Fred Stluka -- mailto:f...@bristle.com  --
> http://bristle.com/~fred/
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
> Open Source: Without walls and fences, we need no Windows or Gates.
> --
> On 4/19/16 12:12 PM, Avraham Serour wrote:
>
> I don't think you would gain anything by separating your models to a
> different repository, what are you trying to gain here?
>
> if you put a maintenance page when doing migrations it won't matter if the
> models are from a different package or not.
>
> you could still run migrations on a live system, you just should take into
> account that there could still be parts of the system using something is
> not there yet/anymore
>
> so you should break migrations into 2 whenever you are adding or removing
> something.
>
> when adding a model or field you should first run the migrations and only
> after that deploy the new code using the new model/field
>
> when removing something you should first stop using it and then migrate.
>
> you could plan your deployment/releases and know in advance if you are
> either adding or removing something and never add and remove in the same
> release
> meaning commit and deploy the model and only after that commit the code
> using the new model
>
> or you can checkout the code on the side and runs migrations using this
> separate env, this way you could add a new model and use it in the same
> commit.
>
> for removing you can just do it backwards.
>
>
> Avraham
>
>
>
> On Tue, Apr 19, 2016 at 3:38 AM,  wrote:
>
>> Hey,
>>
>> I have two issues I'm looking at solving at work, and I'm looking for a
>> couple suggestions as to how other people have solved this.  The two things
>> are:
>>
>> * scale out their django installation to allow for smaller releases (I'm
>> thinking microservices, but it could also be internal django apps or who
>> knows what else)
>> * minimizing the impact of migrations during releases (aka we want to be
>> able to release in the middle of the afternoon
>>
>> Currently we put up a maintenance page whenever we are doing database
>> operations (aka migrations).  This seems like a recommended best practice.
>>
>> One way I was thinking about addressing this issue was to break all of
>> our models out into a separate repo.  That way we'd only need to deploy
>> migrations when the models themselves have deployed.  For code that needs
>> the models, we could pip install the repo as an app and away we go.
>> Likewise it seems like I could break up different parts of our app via a
>> similar strategy.
>>
>> Does this seem viable?  How have other people solved this kind of problem?
>>
>> Thanks,
>>
>> -Ben
>> --
>> 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/e5fd0359-9e8b-4cce-b3e1-4880951a2a8e%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

Re: No Downtime Code Releases

[Vijay Khemlani]

Also, you don't need to restart Apache / nginx or whatever, or delete the
pyc files, just reload uwsgi / gunicorn.

On Tue, Apr 19, 2016 at 6:48 PM, Avraham Serour  wrote:

> you can easily do code reloading with uwsgi graceful reload, no user will
> ever know you reloaded your application, no need to juggle, I mean you
> aren't using mod_wsgi or anything like that right?
>
> On Tue, Apr 19, 2016 at 10:07 PM, Fred Stluka  wrote:
>
>> Ben,
>>
>> I minimize downtime as much as possible by doing things in
>> advance like copying all of the new files to a staging area on
>> the PROD system, automatically inserting PROD passwords,
>> running collectstatic, dumping the DB in case of problems,
>> etc.  Then, I put up the maintenance page, quickly rsync the
>> new files into place, run migrations, and hide the maintenance
>> page.
>>
>> We used to shoot for releases with no downtime by copying
>> the *.py files into place, and letting Django notice and re-load
>> the *.pyc files automatically, but we ran onto some strange
>> issues sometimes.  Seems like Django continued to use some
>> of the cached *.pyc files for a while.
>>
>> It's worked out better to always delete all *.pyc files before
>> rsyncing the *.py files into place, and to always restart the
>> Apache server just before hiding the maintenance page, so
>> we're sure everything gets reloaded cleanly.
>>
>> This has also been a good idea as we've added more caching:
>> - Template files
>> - Fully assembled pages
>> - DB data
>> - etc.
>>
>> Hope this helps,
>> --Fred
>> --
>> Fred Stluka -- mailto:f...@bristle.com  --
>> http://bristle.com/~fred/
>> Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
>> Open Source: Without walls and fences, we need no Windows or Gates.
>> --
>> On 4/19/16 12:12 PM, Avraham Serour wrote:
>>
>> I don't think you would gain anything by separating your models to a
>> different repository, what are you trying to gain here?
>>
>> if you put a maintenance page when doing migrations it won't matter if
>> the models are from a different package or not.
>>
>> you could still run migrations on a live system, you just should take
>> into account that there could still be parts of the system using something
>> is not there yet/anymore
>>
>> so you should break migrations into 2 whenever you are adding or removing
>> something.
>>
>> when adding a model or field you should first run the migrations and only
>> after that deploy the new code using the new model/field
>>
>> when removing something you should first stop using it and then migrate.
>>
>> you could plan your deployment/releases and know in advance if you are
>> either adding or removing something and never add and remove in the same
>> release
>> meaning commit and deploy the model and only after that commit the code
>> using the new model
>>
>> or you can checkout the code on the side and runs migrations using this
>> separate env, this way you could add a new model and use it in the same
>> commit.
>>
>> for removing you can just do it backwards.
>>
>>
>> Avraham
>>
>>
>>
>> On Tue, Apr 19, 2016 at 3:38 AM,  wrote:
>>
>>> Hey,
>>>
>>> I have two issues I'm looking at solving at work, and I'm looking for a
>>> couple suggestions as to how other people have solved this.  The two things
>>> are:
>>>
>>> * scale out their django installation to allow for smaller releases (I'm
>>> thinking microservices, but it could also be internal django apps or who
>>> knows what else)
>>> * minimizing the impact of migrations during releases (aka we want to be
>>> able to release in the middle of the afternoon
>>>
>>> Currently we put up a maintenance page whenever we are doing database
>>> operations (aka migrations).  This seems like a recommended best practice.
>>>
>>> One way I was thinking about addressing this issue was to break all of
>>> our models out into a separate repo.  That way we'd only need to deploy
>>> migrations when the models themselves have deployed.  For code that needs
>>> the models, we could pip install the repo as an app and away we go.
>>> Likewise it seems like I could break up different parts of our app via a
>>> similar strategy.
>>>
>>> Does this seem viable?  How have other people solved this kind of
>>> problem?
>>>
>>> Thanks,
>>>
>>> -Ben
>>> --
>>> 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/e5fd0359-9e8b-4cce-b3

Re: No Downtime Code Releases

[graeme]

On Wednesday, April 20, 2016 at 3:19:59 AM UTC+5:30, Avraham Serour wrote:
>
> you can easily do code reloading with uwsgi graceful reload, no user will 
> ever know you reloaded your application, no need to juggle, I mean you 
> aren't using mod_wsgi or anything like that right?
>

mod_wsgi in daemon mode also has graceful reload: 
https://modwsgi.readthedocs.org/en/develop/user-guides/reloading-source-code.html#reloading-in-daemon-mode
 

Graceful reloading by itself does not really solve the problem - the 
biggest problem is ensuring migrations do not break code (.e.g because a 
column is missing).



> On Tue, Apr 19, 2016 at 10:07 PM, Fred Stluka  > wrote:
>
>> Ben,
>>
>> I minimize downtime as much as possible by doing things in 
>> advance like copying all of the new files to a staging area on 
>> the PROD system, automatically inserting PROD passwords, 
>> running collectstatic, dumping the DB in case of problems, 
>> etc.  Then, I put up the maintenance page, quickly rsync the 
>> new files into place, run migrations, and hide the maintenance
>> page.
>>
>> We used to shoot for releases with no downtime by copying
>> the *.py files into place, and letting Django notice and re-load
>> the *.pyc files automatically, but we ran onto some strange 
>> issues sometimes.  Seems like Django continued to use some
>> of the cached *.pyc files for a while.
>>
>> It's worked out better to always delete all *.pyc files before 
>> rsyncing the *.py files into place, and to always restart the 
>> Apache server just before hiding the maintenance page, so 
>> we're sure everything gets reloaded cleanly.
>>
>> This has also been a good idea as we've added more caching:
>> - Template files
>> - Fully assembled pages
>> - DB data
>> - etc.
>>
>> Hope this helps,
>> --Fred 
>> --
>> Fred Stluka -- mailt...@bristle.com  -- 
>> http://bristle.com/~fred/ 
>> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! 
>> Open Source: Without walls and fences, we need no Windows or Gates. 
>> --
>> On 4/19/16 12:12 PM, Avraham Serour wrote:
>>
>> I don't think you would gain anything by separating your models to a 
>> different repository, what are you trying to gain here? 
>>
>> if you put a maintenance page when doing migrations it won't matter if 
>> the models are from a different package or not.
>>
>> you could still run migrations on a live system, you just should take 
>> into account that there could still be parts of the system using something 
>> is not there yet/anymore
>>
>> so you should break migrations into 2 whenever you are adding or removing 
>> something.
>>
>> when adding a model or field you should first run the migrations and only 
>> after that deploy the new code using the new model/field
>>
>> when removing something you should first stop using it and then migrate.
>>
>> you could plan your deployment/releases and know in advance if you are 
>> either adding or removing something and never add and remove in the same 
>> release
>> meaning commit and deploy the model and only after that commit the code 
>> using the new model
>>
>> or you can checkout the code on the side and runs migrations using this 
>> separate env, this way you could add a new model and use it in the same 
>> commit.
>>
>> for removing you can just do it backwards.
>>
>>
>> Avraham
>>
>>
>>
>> On Tue, Apr 19, 2016 at 3:38 AM, > 
>> wrote:
>>
>>> Hey,
>>>
>>> I have two issues I'm looking at solving at work, and I'm looking for a 
>>> couple suggestions as to how other people have solved this.  The two things 
>>> are:
>>>
>>> * scale out their django installation to allow for smaller releases (I'm 
>>> thinking microservices, but it could also be internal django apps or who 
>>> knows what else)
>>> * minimizing the impact of migrations during releases (aka we want to be 
>>> able to release in the middle of the afternoon
>>>
>>> Currently we put up a maintenance page whenever we are doing database 
>>> operations (aka migrations).  This seems like a recommended best practice.
>>>
>>> One way I was thinking about addressing this issue was to break all of 
>>> our models out into a separate repo.  That way we'd only need to deploy 
>>> migrations when the models themselves have deployed.  For code that needs 
>>> the models, we could pip install the repo as an app and away we go.  
>>> Likewise it seems like I could break up different parts of our app via a 
>>> similar strategy.
>>>
>>> Does this seem viable?  How have other people solved this kind of 
>>> problem?
>>>
>>> Thanks,
>>>
>>> -Ben
>>> -- 
>>> 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/dj