Installing via Tutorial Part 2 / MacOSX / Can't create a superuser due to locale() problem.

[Bill Torcaso]

Hi,
I'm working through the tutorail.  Part 1 was fine, and part 2 shows me the 
site with the light blue background.  I proceed to make my first app, 
'djangotest'.

   1. I run django-admin.py and get a project
   2. I edit settings.py to select sqlite3, and put in an absolute path to 
   a sqlite db file.  I leave 'America/Chicago' unchanged.  the same error 
   happens if I change it to my timezone in EST.
   3. When I run syncdb, I get this error.  I look in the source and it has 
   something to do with 'locale' and a tuple of (None, None).  Please help.


[-] python manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site

You just installed Django's auth system, which means you don't have any 
superusers defined.
Would you like to create one now? (yes/no): yes
Traceback (most recent call last):
  File "manage.py", line 10, in 
execute_from_command_line(sys.argv)
  File 
"/Library/Python/2.7/site-packages/django/core/management/__init__.py", 
line 443, in execute_from_command_line
utility.execute()
  File 
"/Library/Python/2.7/site-packages/django/core/management/__init__.py", 
line 382, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Library/Python/2.7/site-packages/django/core/management/base.py", 
line 196, in run_from_argv
self.execute(*args, **options.__dict__)
  File "/Library/Python/2.7/site-packages/django/core/management/base.py", 
line 232, in execute
output = self.handle(*args, **options)
  File "/Library/Python/2.7/site-packages/django/core/management/base.py", 
line 371, in handle
return self.handle_noargs(**options)
  File 
"/Library/Python/2.7/site-packages/django/core/management/commands/syncdb.py", 
line 110, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive, db)
  File "/Library/Python/2.7/site-packages/django/core/management/sql.py", 
line 189, in emit_post_sync_signal
interactive=interactive, db=db)
  File "/Library/Python/2.7/site-packages/django/dispatch/dispatcher.py", 
line 172, in send
response = receiver(signal=self, sender=sender, **named)
  File 
"/Library/Python/2.7/site-packages/django/contrib/auth/management/__init__.py", 
line 73, in create_superuser
call_command("createsuperuser", interactive=True, database=db)
  File 
"/Library/Python/2.7/site-packages/django/core/management/__init__.py", 
line 150, in call_command
return klass.execute(*args, **defaults)
  File "/Library/Python/2.7/site-packages/django/core/management/base.py", 
line 232, in execute
output = self.handle(*args, **options)
  File 
"/Library/Python/2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py",
 
line 70, in handle
default_username = get_default_username()
  File 
"/Library/Python/2.7/site-packages/django/contrib/auth/management/__init__.py", 
line 105, in get_default_username
default_username = get_system_username()
  File 
"/Library/Python/2.7/site-packages/django/contrib/auth/management/__init__.py", 
line 85, in get_system_username
return getpass.getuser().decode(locale.getdefaultlocale()[1])
TypeError: decode() argument 1 must be string, not None


Thanks,

  --  Bill 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/GmlYGnGfpfYJ.
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.

Re: Installing via Tutorial Part 2 / MacOSX / Can't create a superuser due to locale() problem.

[Bill Torcaso]

On Friday, June 22, 2012 3:46:42 PM UTC-4, Bill Torcaso wrote:
>
>
> Hi,
> I'm working through the tutorail.  Part 1 was fine, and part 2 shows me 
> the site with the light blue background.  I proceed to make my first app, 
> 'djangotest'.
>
>1. I run django-admin.py and get a project
>2. I edit settings.py to select sqlite3, and put in an absolute path 
>to a sqlite db file.  I leave 'America/Chicago' unchanged.  the same error 
>happens if I change it to my timezone in EST.
>3. When I run syncdb, I get this error.  I look in the source and it 
>has something to do with 'locale' and a tuple of (None, None).  Please 
> help.
>
>
> [-] python manage.py syncdb
> Creating tables ...
> Creating table auth_permission
> Creating table auth_group_permissions
> Creating table auth_group
> Creating table auth_user_user_permissions
> Creating table auth_user_groups
> Creating table auth_user
> Creating table django_content_type
> Creating table django_session
> Creating table django_site
>
> You just installed Django's auth system, which means you don't have any 
> superusers defined.
> Would you like to create one now? (yes/no): yes
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File 
> "/Library/Python/2.7/site-packages/django/core/management/__init__.py", 
> line 443, in execute_from_command_line
> utility.execute()
>   File 
> "/Library/Python/2.7/site-packages/django/core/management/__init__.py", 
> line 382, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/Library/Python/2.7/site-packages/django/core/management/base.py", 
> line 196, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File "/Library/Python/2.7/site-packages/django/core/management/base.py", 
> line 232, in execute
> output = self.handle(*args, **options)
>   File "/Library/Python/2.7/site-packages/django/core/management/base.py", 
> line 371, in handle
> return self.handle_noargs(**options)
>   File 
> "/Library/Python/2.7/site-packages/django/core/management/commands/syncdb.py",
>  
> line 110, in handle_noargs
> emit_post_sync_signal(created_models, verbosity, interactive, db)
>   File "/Library/Python/2.7/site-packages/django/core/management/sql.py", 
> line 189, in emit_post_sync_signal
> interactive=interactive, db=db)
>   File "/Library/Python/2.7/site-packages/django/dispatch/dispatcher.py", 
> line 172, in send
> response = receiver(signal=self, sender=sender, **named)
>   File 
> "/Library/Python/2.7/site-packages/django/contrib/auth/management/__init__.py",
>  
> line 73, in create_superuser
> call_command("createsuperuser", interactive=True, database=db)
>   File 
> "/Library/Python/2.7/site-packages/django/core/management/__init__.py", 
> line 150, in call_command
> return klass.execute(*args, **defaults)
>   File "/Library/Python/2.7/site-packages/django/core/management/base.py", 
> line 232, in execute
> output = self.handle(*args, **options)
>   File 
> "/Library/Python/2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py",
>  
> line 70, in handle
> default_username = get_default_username()
>   File 
> "/Library/Python/2.7/site-packages/django/contrib/auth/management/__init__.py",
>  
> line 105, in get_default_username
> default_username = get_system_username()
>   File 
> "/Library/Python/2.7/site-packages/django/contrib/auth/management/__init__.py",
>  
> line 85, in get_system_username
> return getpass.getuser().decode(locale.getdefaultlocale()[1])
> TypeError: decode() argument 1 must be string, not None
>
>
> Thanks,
>
>   --  Bill 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/12tQAZJkzyUJ.
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.

Re: Installing via Tutorial Part 2 / MacOSX / Can't create a superuser due to locale() problem.

[Bill Torcaso]

Thanks, Kurtis.  More googling brought me the answer, found here:

  
  http://level09.com/54/tip-how-to-fix-django-locale-problem-on-mac-osx-10-7

The solution is to explicitly export LANG and a bunch of LC_* local 
variables in ~/.bashrc.  This may be a workaround, but it's good enough for 
me.

The precise problem seems to be that there is no default locale set, not 
even the C locale, so locale.get_default_locale() returns (None, None), and 
calling code blows up.

Since the link mentions Mac OSX 10.7 and was posted two months ago, it 
seems likely that this is a recently-created problem on Macs.  Whoever 
maintains the tutorial might consider mentioning this, if only in a 
footnote.

Cheers,  --  Bill

On Friday, June 22, 2012 4:22:22 PM UTC-4, Kurtis wrote:
>
> Did you get an opportunity to type anything after "yes"? Or did it 
> just blow up at that point? 
>
> Based on the traceback, it looks like it is having trouble getting 
> your system's default username. I've never really noticed that it has 
> that functionality before but I wonder if there's something "weird" 
> about your System's configuration? 
>
> Which version of Django are you using? 
>
> To by-pass this (until you get the real problem worked out) give this a 
> shot: 
>
> python manage.py shell # This will open up a terminal-shell in your 
> Django Environment 
> from django.contrib.auth.models import User # Import the User Model so 
> we can create a new user 
> user = User.objects.create_user(username='someusername', 
> password='somepassword', is_superuser=True) # Create the new User 
> (Remember these credentials) 
> user.save() # Save the User 
> exit() # Exit the Python Shell 
>
> And you should be all good to go. 
>
> On Fri, Jun 22, 2012 at 3:46 PM, Bill Torcaso  
> wrote: 
> > 
> > 
> > Hi, 
> > I'm working through the tutorail.  Part 1 was fine, and part 2 shows me 
> the site with the light blue background.  I proceed to make my first app, 
> 'djangotest'. 
> > 
> > I run django-admin.py and get a project 
> > I edit settings.py to select sqlite3, and put in an absolute path to a 
> sqlite db file.  I leave 'America/Chicago' unchanged.  the same error 
> happens if I change it to my timezone in EST. 
> > When I run syncdb, I get this error.  I look in the source and it has 
> something to do with 'locale' and a tuple of (None, None).  Please help. 
> > 
> > 
> > [-] python manage.py syncdb 
> > Creating tables ... 
> > Creating table auth_permission 
> > Creating table auth_group_permissions 
> > Creating table auth_group 
> > Creating table auth_user_user_permissions 
> > Creating table auth_user_groups 
> > Creating table auth_user 
> > Creating table django_content_type 
> > Creating table django_session 
> > Creating table django_site 
> > 
> > You just installed Django's auth system, which means you don't have any 
> superusers defined. 
> > Would you like to create one now? (yes/no): yes 
> > Traceback (most recent call last): 
> >   File "manage.py", line 10, in  
> > execute_from_command_line(sys.argv) 
> >   File 
> "/Library/Python/2.7/site-packages/django/core/management/__init__.py", 
> line 443, in execute_from_command_line 
> > utility.execute() 
> >   File 
> "/Library/Python/2.7/site-packages/django/core/management/__init__.py", 
> line 382, in execute 
> > self.fetch_command(subcommand).run_from_argv(self.argv) 
> >   File 
> "/Library/Python/2.7/site-packages/django/core/management/base.py", line 
> 196, in run_from_argv 
> > self.execute(*args, **options.__dict__) 
> >   File 
> "/Library/Python/2.7/site-packages/django/core/management/base.py", line 
> 232, in execute 
> > output = self.handle(*args, **options) 
> >   File 
> "/Library/Python/2.7/site-packages/django/core/management/base.py", line 
> 371, in handle 
> > return self.handle_noargs(**options) 
> >   File 
> "/Library/Python/2.7/site-packages/django/core/management/commands/syncdb.py",
>  
> line 110, in handle_noargs 
> > emit_post_sync_signal(created_models, verbosity, interactive, db) 
> >   File 
> "/Library/Python/2.7/site-packages/django/core/management/sql.py", line 
> 189, in emit_post_sync_signal 
> > interactive=interactive, db=db) 
> >   File 
> "/Library/Python/2.7/site-packages/django/dispatch/dispatcher.py", line 
> 172, in send 
> > response = receiver(signal=self, sender=sender, 

Is Tutorial / Part 4 wrong? (or is it me?)

[Bill Torcaso]

Django is great, and the tutorial is great.  I'm having a problem at the 
very end of tutorial-4.

I try to use generic views, and I get an error when I Redirect from the 
POST request in vote() to the Results page.  Details below.

The tutorial code says to put this in my urls.py:

url(r'^(?P\d+)/results/$',
DetailView.as_view(
model=Poll,
template_name='polls/results.html')
,name="poll_results" 
),

And this in my views.py:

 from django.shortcuts import get_object_or_404, render_to_response
from django.http import HttpResponseRedirect, HttpResponse
from django.core.urlresolvers import reverse
from django.template import RequestContext
from polls.models import Choice, Poll


def vote(request, poll_id):
p = get_object_or_404(Poll, pk=poll_id)
try:
selected_choice = p.choice_set.get(pk=request.POST['choice'])
except (KeyError, Choice.DoesNotExist):
# Redisplay the poll voting form.
return render_to_response('polls/detail.html', {
'poll': p,
'error_message': "You didn't select a choice.",
}, context_instance=RequestContext(request))
else:   
selected_choice.votes += 1
selected_choice.save()
# Always return an HttpResponseRedirect after successfully dealing
# with POST data. This prevents data from being posted twice if a
# user hits the Back button.

 

return HttpResponseRedirect(reverse('polls_results', args=(p.id,)))
### OKAY:return HttpResponseRedirect("/polls/%i/results" % p.id)
### OKAY:return render_to_response("polls/results.html", 
{"poll": p})
### BAD:   return 
HttpResponseRedirect(reverse('polls.views.results', args=(p.id,)))



NoReverseMatch at /polls/4/vote/

Reverse for 'polls_results' with arguments '(4,)' and keyword arguments 
'{}' not found.
  
*Request Method:*
 
POST
  
*Request URL:*
 
http://127.0.0.1:8000/polls/4/vote/
  
*Django Version:*
 
1.4
  
*Exception Type:*
 
NoReverseMatch
  
*Exception Value:*
 
Reverse for 'polls_results' with arguments '(4,)' and keyword arguments 
'{}' not found.
  
*Exception Location:*
 
/Library/Python/2.7/site-packages/django/core/urlresolvers.py in 
_reverse_with_prefix, line 407
  
*Python Executable:*
 
/usr/bin/python
  
*Python Version:*
 
2.7.1
  
*Python Path:*
 
['/Users/s3/Desktop/CODE/APPSS3/EdAssistant/experiments/djtest',

 
'/Library/Python/2.7/site-packages/mercurial-2.0.2-py2.7-macosx-10.7-intel.egg',

 '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',

 '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',

 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',

 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',

 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',

 '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',

 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',

 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',

 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload',

 
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC',

 '/Library/Python/2.7/site-packages']
  
*Server time:*
 
Mon, 16 Jul 2012 11:53:21 -0500
  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/f-sjN1OtNuwJ.
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.

Migrating into Django 1.9; question about autoescape

[Bill Torcaso]

Hello all,

I have the task of migrating a very old website from Django 1.7 to either 
Django 1.11 or 2.0, depending on the effort.

My plan is to go from 1.7 --> 1.8 --> 1.9 -->1.10 --> 1.11, adapting the 
codebase as I go.  It's been easy enough until I arrive at 1.9, and the 
change in template-rendering in which "autoescape" defaults to "on".

Now a lot of my payload is arriving at the browser with my HTML tags 
escaped.  For example,

   gets rendered as<button>

I have no argument with the autoescape-on default setting.  But I am unsure 
how to proceed, and how large the effort will be.  As background, I am a 
seasoned back-end programmer and a lightweight in HTML and template issues.

I see these alternatives.  Are there any others?


   1. Get to the Template Engine object and set its autoescape attribute to 
   "off".  This loses the protection that autoescape-on provides, restores the 
   Django 1.8 behavior, and let me proceed with the smallest amount of effort.
   
   Is this the template engine I need?  
"django.core.context_processors.request"  
   And how do I get to the object?
   
   2. Visit all of my HTML files and put "{% autoescape off %}" everywhere.
   
   I put "{% autoescape off %}" in my base.html, and it partially solved 
   the problem.  But it did not get everything.
   
   This is a medium amount of effort, and if I make a mistake the users 
   will have a bad experience.
   
   3. Visit all of my code and all of my templates, carefully converting 
   into the world of autoescape-on.

Thanks in advance,

  ---  Bill Torcaso

-- 
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/ada6d206-7daa-4c9f-a124-dab988909093%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: When do I need a new app within the site?

[Bill Torcaso]

This is an indirect reply --- but I like the book "Two Scoops of Django".  
It is a strong explanation of Django best practices.  (The "scoops" are 
scoops of ice cream in the fictional ice cream store of the examples).

Hope this helps.

On Thursday, February 22, 2018 at 7:22:36 AM UTC-5, Cictani wrote:
>
> Hi,
>
> I'm just beginning developing a new app(s) and I'm wondering when I need 
> to add a new app. if one app uses models from another app is that a hint 
> that these two apps are acutally one app or is this still ok in terms of 
> good design?
>
> Let's say I have a customer app (with customer models, admins etc) and a 
> booking app which of course uses the customer model. Would it be good to 
> have two apps or would it be actually only a booking app which includes all 
> the models, logic etc from the customer app?
>
> Thanks in advance
>
> Andreas
>

-- 
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/ff8a7963-db3a-4a1c-87e5-c722357efa3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling Postgres database credentials in django for deployment.

[Bill Torcaso]

I have a concern about using environment variables to hold secret 
information, and an opinion about it.  

IF

DEBUG is enabled, and there is a 500 server internal error, and the default 
500 template is used to render the response, 


THEN

*all of your secret information is shown in the browser output*


Of course, DEBUG should never be enabled in production.  But a single human 
error might make it happen. 

I would prefer to trust Github security and long passwords than to think I 
am infallible about setting DEBUG. 

Note that this is certainly what happens when I run on a Vagrant VM, and I 
think it would be the same in a Docker-like container.




On Thursday, March 29, 2018 at 4:24:40 PM UTC-4, prince gosavi wrote:
>
> Hi,
> I have made a django project and want to deploy it on cloud.
> Before that i want to decouple all the private information.
> I want to decouple the database info too, like the username password etc.
> Any help is appreciated.
>

-- 
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/f5a1498a-3383-4219-b10e-e3e64f164658%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use self-increasing arguments in numeric for-loop in Django

[Bill Torcaso]

I an new-ish to Django, and I ask this to hear from more experienced users 
whether this would work at all, and whether it would be considered a good 
or bad practice.

Goal: given an object and an integer index, retrieve the sub-object at that 
index within the incoming object.

Method:  Write a custom tag.  Provide the tag with the larger object, and 
the integer index.  Return the sub-object at that index (or whatever 
field(s) are needed).

Usage:

  {% for i in metarange %}{% graphobject_get_by_index graphobject {{ i }} 
%}  {% endfor %}



In this particular case, there is an issue about whether the sub-object can 
be null, for some definition of null.  There are various ways to deal with 
that.

Again, I am new-ish to Django.  Is there a similar approach in which 
'get_by_index' is a method on class Graphobject, such that this would work?

{% graphobject.get_by_index {{ i }} %}

Thanks for any explanation about these approaches.


On Thursday, April 19, 2018 at 12:01:37 PM UTC-4, shaw...@gmail.com wrote:
>
> I am currently working on django.
>
> I have a list of values which stored in 'graphobject', and 'metarange' is 
> defined as range(0,59). In that case, how could I use numbers as argument 
> to display the value stored in graphobject? I tried using following codes 
> but it doesn't work
>
>
> {% for i in metarange %}{% if graphobject.i != '' %}{{ graphobject.i }}{% 
> endif %}{% endfor %}
>
>
> Please tell me how could I do this?
>

-- 
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/9c162dd2-201b-4370-bac0-f3afb3db163a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling Postgres database credentials in django for deployment.

[Bill Torcaso]

I waited a while to answer this, and my answer comes in three distinct 
parts.

#-

Question:  what is the danger is using environment variables to hold secret 
info?

Answer:  The Django runtime will dump secret info from environment 
variables into an HTTP response, in some circumstances.  Once secret info 
is in an HTTP response on the open internet, the secrecy is compromised.  
As far as I know, the Django runtime will never dump the contents of the 
settings object into an HTTP response.

The defense of environment variables, as described in this thread are all 
vulnerable to human error.  Except possibly the one by Mike DeWhirst.

The human error is as simple as this:

On Elastic Beanstalk,

git checkout DEBUG_branch 

eb use  PRODUCTION_environment

eb deploy 

 
#-

Question: what did I mean by "github security" as protection for secret 
information stored in a plaintext file in the github repository?

Answer:  There are two ways to access a file in a private github 
repository.  One way is through hacking my password, and the other is by 
breaching the protection that github applies to keep a private repository 
private.

My github password is random and has more than 120 bits of entropy.  In 
practical terms, is is safe from brute-force hacking.  As for the methods 
that github uses to keep a repository private, I have no specific 
information.  But I take it on faith that smart people have thought about 
it; and that's what I mean by "trusting github security".

#-

Lastly,  I'm not trying to persuade anybody of the one true way to do 
things.  Every method of storing secrets has strengths and weaknesses.  I 
have an opinion: using environment variables is more dangerous than 
generally believed, and, in my opinion, keeping secrets in plaintext in the 
repository is less dangerous than generally believed.

-- 
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/5e34a2a5-e226-4688-9d53-d5151bb741be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Managing multiple user types in Django

[Bill Torcaso]

I inherited a system which has one User model, and a Profile model that is 
1-to-1 with User.  The type-of-user information is carried in a required 
"role" property in the Profile.  I think that is a well-established 
approach.

I am curious to hear what people think of the tradeoffs between (User + 
Profile) and (User-base-class + subclasses).

On Tuesday, May 15, 2018 at 12:41:50 PM UTC-4, Vijay Khemlani wrote:
>
> I would make a UserType table and have a foreign key from your user model 
> to it, or maybe just have an enumerated type in your user model depending 
> on how much custom logic there is to each user type.
>
> On Tue, May 15, 2018 at 11:50 AM Frankline  > wrote:
>
>> Hello Everyone,
>>
>> I am developing an API based on Django Rest Framework 
>> . Currently I have 4 user types 
>> i.e. Buyer, Merchant, Insurer, and Admin.
>>
>> The system I'm developing has an *API endpoint* and a *Dashboard* view.
>>
>> Each of the above user types have different fields and may need to login 
>> to the system at one point, so having one user model is the best way to go. 
>> Note that, a user can only be of one type.
>>
>> However, only the merchant will be actively using the API endpoint.
>>
>> My question is then, how will I be able to manage the different user 
>> types in the system?
>>
>> My current options are:
>>
>> 1.
>>
>>1. class BaseUser(AbstractBaseUser):
>>2. ...
>>3.  
>>4. class Buyer(BaseUser):
>>5. ...
>>6. 
>>
>>
>>1. class Merchant(BaseUser):
>>2. ...
>>3. 
>>
>>
>>1. class Insurer(BaseUser):
>>2. ...
>>
>>
>> 2. 
>>
>>
>>1. from django.db import models
>>2. from django.contrib.auth.models import User
>>3.  
>>4. class Buyer(models.Model):
>>5. user = models.OneToOneField(User)
>>6.  
>>7. class Merchant(models.Model):
>>8. user = models.OneToOneField(User)
>>9. 
>>
>>
>>1. class Insurer(models.Model):
>>2. user = models.OneToOneField(User)
>>
>>
>>
>>1. ...
>>
>>
>> Which is the most optimal way of handling this?
>>
>>1. 
>>
>>
>>
>>
>> -- 
>> 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/CAEAUGdVwB_RrOP_s9Oj5fe6AoOXJ9qpPLUKpE%2BbAO_NLGMRn6g%40mail.gmail.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/649bdc12-cf5a-4f01-8be6-7620854791d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: better way to create a dictionary in Django model?

[Bill Torcaso]

You might find it helpful to look at the Wagtail CMS (wagtail.io).  It may 
not solve your problem, but Wagtail stores page-layout information in JSON 
format in a database column.  The JSON can be revised without modifying the 
database schema.

On Wednesday, June 27, 2018 at 8:18:09 AM UTC-4, prateek gupta wrote:
>
> Hi All,
>
> I am using Django 2.0.6 with Python 3.6 and MySql and created a model 
> which maps the db tables to django.
> In my database, I have a column 'config' of type json.
> This column stores the data in a dictionary format like below- 
> {"user_id": "a...@example.com ", "password": "xyz"}
> I need to make it editable via the Django like below screen shot-
>
>
> 
>
> I need your suggestion - what is the best way to achieve this?
> I found a useful link for this purpose -
> how-to-store-a-dictionary-on-a-django-model 
> 
>  but 
> want to take your valuable guidance before proceeding so that I can 
> implement with best practices.
>

-- 
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/95fcc428-ce8b-4de2-82f5-ff081f7099a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A few doubts with an implementation.

[Bill Torcaso]

I didn't deeply consider your problem, but the aspect of doing a repetitive 
task at unrelated time intervals reminds me of how the Unix kernel handles 
the alarm() system call for multiple, unrelated processes.  For you, it 
will take at most one thread to handle any number of users.


   1. Maintain a first-in-first-out queue, sorted by time.
   2. An item in the queue has identifying info about a user, and (*this is 
   the key fact*) a measure of time relative to the queue item before it.
   3. When a new user appears, create a queue entry for that user at the 
   appropriate spot in the time-relative queue.  That might always be at the 
   end, but if different users get the email fetched at different intervals, 
   the insertion spot might be in the interior of the queue.
   4. When a user logs out, or by whatever criteria you chose, scan the 
   list and remove any queue entry that refers to that user.

The API for other code to call the queue-management thread is only two 
things:  

   - Create an entry for this user, at this repetition interval.  
   - Remove the entry this user.

The rest of the code for the queue is internal implementation details.This 
is the action of the queue-management thread:

   1. At start-time, create this thread.  It is idle to start with.
   2. When a user logs in, other code will send a signal to the thread.  
   When a user logs out, likewise send a signal to the queue-management thread.
   3. The thread calculates how long to sleep before waking up and fetching 
   email for the entry at the head of the queue.
   4. When the thread wakes up, it does the work for the item at the head 
   of the queue.  If that work takes a long time, or has complex handling of 
   errors during the work, you might spawn a thread to do the work outside of 
   the queue-management thread.
   5. Remove that queue-head item. Re-insert it at the place in the queue 
   for its next execution on behalf of this user.  That will likely be at the 
   end, but might be in the interior of the queue.
   6. Loop back to #3.





On Monday, July 2, 2018 at 9:36:13 AM UTC-4, Vineeth Sagar wrote:
>
> Problem:
> We are developing a email-CRM. The task at hand is to fetch emails every N 
> minutes or hours. I have received a codebase written by another guy who 
> left the company,my job is to re-write/re-factor. The guy who previously 
> wrote the code started a thread whenever a user logged and he put a 
> time.sleep() inside it, There's no limit on number of threads that can be 
> initialized, if 100 users log in, we will have 100 active threads, he used 
> locks so that at any given time only one thread can be executed. 
>
> Solution:
> It's messy in so many ways(mentioned above) and I think writing django 
> middleware would be appropriate for this task. So here's what I plan to do, 
> using a Django cache I store a Python datetime object and a flag to see if 
> there is any other request that's already retrieving the mails, I don't 
> want multiple requests to retrieving mails at once. Is this a better idea? 
> Are there any other ways to do this particular task?
>
> One more doubt I have is I want the user to know that the mails are being 
> retrieved so he doesn't refresh the page passive-aggressively. How can I do 
> this? I want the user to know it's happening and in the background 
> middleware should be executed, I have to keep retrieving mails and once 
> it's completed I'll execute the view_func parameter received via the 
> process_request hook. 
>
> I am a junior at the company(Start up),I am fairly new to django, I keep 
> reading the documentation and find new things daily,after picking my mind 
> for a day this to me seems best, but please if you have any suggestion let 
> me know. Please help me out. 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+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/f0f061c8-a04f-445a-aa16-210cfd9e693d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django DateField

[Bill Torcaso]

I wonder if this would work: represent ASAP as a legitimate DateTime value 
that is, say, 100 years in the future.  Then a simple reverse sort will 
display all of the ASAP tasks before any others.

This is a hack, and nothing but a hack.  But you could implement it in five 
minutes.

On Thursday, July 5, 2018 at 1:05:47 PM UTC-4, dtdave wrote:
>
> I have a model that contains a datefield which signifies the start date 
> for a task.
> My modelmanager filters the tasks by the start date and the template lists 
> them in the date descending order. Everything is fine with this.
>
> However, now I have been asked to change this so that some projects have a 
> start date of ASAP and others have date.
> These then need to be listed in my template with ASAP tasks coming first 
> and then those with a start date coming in descending order.
>
> I am at a loss as to how to achieve this so would welcome any pointers or 
> ideas.
> 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+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/39402829-7565-464c-92e7-f86bbfcc0a74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: App structure : "One file - One object" - Is there a better way ?

[Bill Torcaso]

I ask this out of genuine curiosity -- how do you edit source code?  I'm 
wondering because that seems inseparable from how you structure your python 
code into files.

I say this without any judgement.  If your brain likes one method per file, 
then you are asking your fingers and eyes to do more work than if you allow 
a complete class definition in one file.

Eclipse and PyCharm both allow you to collapse a method body, so that you 
see only its declaration line.  You can also collapse an entire class 
definition to its declaration, so that you can have multiple class 
declarations in one file and only see one at a time.  I wonder what you 
gain by your approach.

Looking forward to your reply,

  ---  Bill

(I myself mostly use "vi", with bash convenience functions for hopping 
around in the source tree.  I like PyCharm a lot, but it does not cover the 
remote execution scenarios that I need.)

>
>

-- 
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/ab6317bd-ec55-494f-9321-f209c03b8661%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Channels] How to write tests with database access?

[Bill Torcaso]

The question is whether testing asynchronous operations and  is compatible.

In my understanding, Andrew's hint points you in the only good direction.  
You've got to turn the async initiate/complete cycle back into a 
synchronous flow.

You can poll from another thread, or use a message queue, or any of a 
number of approaches.  But there is no way around the need to wait until 
completion before your test the state after completion.

On Saturday, July 28, 2018 at 10:49:39 AM UTC-4, Neraste wrote:
>
> Thanks for the hint, Andrew. I think it is a neat approach. But I start to 
> wonder if asynchronous tests + database manipulation are naturally and 
> painlessly compatible.
>
> Le dimanche 22 juillet 2018 18:44:52 UTC+2, Andrew Godwin a écrit :
>>
>> Asynchronous testing is very hard, unfortunately. I suspect what you are 
>> doing is awaiting the sending of the message, but not awaiting any response 
>> back, so your test continues once it's sent the message into the 
>> application but not waiting for that application to finish processing.
>>
>> The best pattern for this is probably to send something back when you've 
>> finished processing and await receiving that, then you should guarantee 
>> that the work has been finished before your test continues.
>>
>> Andrew
>>
>> On Thu, Jul 19, 2018 at 8:18 AM Neraste  wrote:
>>
>>> Hello Django users,
>>>
>>> This sounds like a pretty newbish question, but I am struggling on how 
>>> to write tests for Django-channels 2 websocket consumers that access the 
>>> database. I am not familiar with pytest and asynchronous programming (the 
>>> bread and butter of Channels testing), so while I caught up with pytest, I 
>>> am still a bit lost between `async` and `await`.
>>>
>>> Using Django/Django-REST, when I test a view method which modifies a 
>>> database object for a given request, here is what I usually do:
>>>
>>>1. Assert the initial state of the object ; 
>>>2. Use the test client to send the request ; 
>>>3. Assert the outcome of the request ; 
>>>4. Assert the final state of the object, which should be different. 
>>>
>>> All of this synchronously. With Channels, I thought I could do the same 
>>> for a consumer method which modifies a database object on a given event:
>>>
>>>1. Assert the initial state of the object ; 
>>>2. Use the test communicator to send the event ; 
>>>3. Assert the final state of the object, which should have changed. 
>>>
>>> All of this asynchronously, as stated in the documentation 
>>> , but 
>>> this is a synchronous test scenario! Obviously, it does not work, as step 
>>> 2. is executed with `await` and step 3. is achieved before step 2. 
>>> finishes. I tried to execute step 2. synchronously using `async_to_sync` 
>>> but it does not work (I can give details).
>>>
>>> I am missing something, how can I test such a consumer method? Is this 
>>> possible? The documentation does not give any hint on this…
>>>
>>> Help would be much appreciated!
>>>
>>> Cheers,
>>>
>>> -- 
>>> Neraste
>>>
>>> -- 
>>> 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/c22c1afb-ff85-5af9-66f6-a94cdc77a545%40gmail.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/e2824e79-cb0b-4d70-9867-884104e0508f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to best secure environment variables (secret key, passwords etc.) stored in .yml files?

[Bill Torcaso]

A couple of years ago I posted on this topic to say that using ENV 
variables is dangerously subject to human error.  If it ever happens that 
(1) you put a server on the public internet with DEBUG on, and (2) a 
visitor can provoke a 5xx server error response, then all of your secrets 
will be dumped in the stack-trace output.

(Yes, I know people will say "don't do that" regarding point #1, and 
similarly say "never publish code with a possible 500 error event".  But if 
it ever happens, you are screwed.  And you won't necessarily know that it 
happened.)

In general, if your secrets are kept in plaintext in your github repository 
and your repository gets compromised, then you have lost everything.

I've tried to think of a way to store the secrets in a plaintext file and 
encrypt the file's contents before committing the ciphertext file to the 
repository.  The question, as always, is where to store they key for 
decrypting the secrets file.

I have an idea in which the encryption key is manufactured on the fly from 
some non-obvious fact about the repository contents.  I'd like to get 
feedback from the Django community about it.

Summary:

   - Put all secret info in a text file, but encrypt the file before it 
   gets committed into the repository.
   
   - *Use an encryption key that is derived from some fact about the files 
   in the repository.*
   
   - At runtime, use that same fact to derive the decryption key for the 
   secrets file.
   
   - Ensure that the runtime server can never reveal the fact that is the 
   basis of the encryption key.


Suppose for example that the encryption key is the SHA-1 hash value of 
urls.py.  This is calculated during the release process, and used to 
encrypt the plaintext secrets file.  Then the encrypted secrets file is 
committed to the repository, and ultimately gets deployed to production.

urls.py obviously changes over time.  But it is constant for any given 
commit of the entire codebase, which is what gets deployed. 

At start-up time, the Django server can open urls.py and hash the contents, 
and use that hash value to decrypt the contents of the secrets file.  As a 
result, the secrets are available at runtime, but they are never stored in 
a plaintext file.

Why is this secure?  It relies on two assumptions.

   1. Ensure that the contents of urls.py will never be published as part 
   of an HTTPResponse.
   
   When this is true, the runtime server cannot reveal the decryption key 
   for the encrypted secrets file.  That is to say, do not write a management 
   command with name "getthesecretdecryptionkey".
   
   2. Using security-through-obscurity, do not always use the same file 
   (urls.py) as the basis of the hash value.  Instead, use some obscure 
   selection criteria like "the seventh-largest .PY source file in the tree; 
   in case of a tie, use the alphabetically last file".
   
   Similarly, do not always use the same hash method; instead, select a 
   hash method from a list like [ "SHA-1, SHA-256, "MD5", ] by taking the size 
   of urls.py modulo the length of that list.

I look forward to hearing comments about this approach.

Bill Torcaso

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/91ae856c-8408-44c6-893d-12e1189a418d%40googlegroups.com.

Re: Different results of running pure SQL query from Django and from PGAdmin

[Bill-Torcaso-Oxfam]

I'd be interested to see a printout of 'columns' and 'cursor.description'.

One explanation would be that your for-loop is not actually accessing the 
data that you think it is, or that your query is not actually fetching the 
data that you think it is.  

No criticism of your query implied - just trying to get more visibility 
into the actual results.  

-- 
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/cd6767a9-b3f1-4971-9f12-dc818092f697%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running django tests with postgres

[Bill-Torcaso-Oxfam]

I two comments, and as always Your Milage May Vary.


   - I wonder if you have the right indexes on your Postgres database? The 
   previous people report much faster completion times for test that use 
   Postgres as the database.  Perhaps your domain is just hard (and you 
   description makes it sound that way), but "Explain Plan" might be your best 
   friend here.
   
   - Sqlite does not enforce length limit constraints on text fields.  You 
   can declare a field to be CharField(max_length=200), and Sqlite will 
   happily put a longer string into the field.  Postgres will not.
   
   This came up when I was importing data from an older generation of our 
   product.  My custom import code ran successfully against Sqlite and the 
   exact same command failed against Postgres.
   
   - (And yes, I said only two points.  But this just occurs to me...)
   
   Can you divide your test suite into distinct independent chunks, and run 
   them in parallel?  Either against one common database or using one database 
   per test-chunk?
   
   
On Friday, September 14, 2018 at 11:32:49 AM UTC-4, Hezi Halpert wrote:
>
> I would like to share with you an issue we encounter while moving from 
> sqlite to postgres with heavily use of Django testing.
>
> We have Django app with ~700 tests. Most of them accessing database. We 
> recently migrated the database from sqlite to postgres. 
> Many of our tests were written in a way that compares actual pk’s 
> (hard-coded pks or just file/json comparisons) . Since Django testing on 
> sqlite (testcases.TestCase class) creates in-memory database (which is 
> being reseted every unit test by default), we never had a problem with it.
> However, Django TestCase on postgres create completely another test db 
> which preserves the pk sequences between different tests. And since many of 
> our tests were written in a way that compares actual pk’s they all start 
> fail - depends on the exact tests execution order.
> Even tests which expect some pk and are were not failed yet, can 
> potentially failed in the future - depends on adding/editing other tests 
> which may change the db sequence
>
> We consider the following solutions:
>
>1. Move to TransactionTestCase (instead of TestCase) and use 
>“reset_sequences = True” flag. Cons: TransactionTestCase reduces 
>performance dramatically (~4 times longer in some of the tests) 
>2. Refactor all failed tests: remove all hard-coded references to the 
>pk. Cons: Require much Dev effort (we had more then 70 such tests)
>3. Route the database in settings.py such it will use sqlite instead 
>of postgres when running tests. Cons: It will not actually test the real 
>scenarios - not an option
>4. Combine reset_sequences flag with TestCase in our own version to 
>TestCase: OurTestCase class and make everything to inherit from it. This 
> is 
>the option we finally decided of. See below.
>
>
> from django.test import TestCase, testcases
>
>
> class OurTestCase(TestCase):
> reset_sequences = True
>
> def _fixture_setup(self):
> for db_name in self._databases_names(include_mirrors=False):
> if self.reset_sequences:
> self._reset_sequences(db_name)
> if self.fixtures:
> call_command('loaddata', *self.fixtures, **{'verbosity': 0, 
> 'database': db_name})
> if not testcases.connections_support_transactions():
> self.setUpTestData()
> return super(TestCase, self)._fixture_setup()
> self.atomics = self._enter_atomics()
>
>
> Another problem of these kind of tests is the default ordering assumption 
> of Django which changes significantly between postgres and sqlite when 
> testing.
> Therefore, models included in such tests must have a hint for Django 
> regarding the default ordering retrieval. 
> Our solution was to make all models inherit from DexterModelDefaultOrder 
> (below) 
>
>
> class DexterModelDefaultOrder(models.Model):
> class Meta:
> abstract = True
> ordering = ['id']
>
>
>
> I hope it (will) help someone
>
>

-- 
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/1e8ec552-d793-4161-ba10-070263586698%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update django 1.8 project to 2.0 lts

[Bill-Torcaso-Oxfam]

I strongly recommend this approach:

My experience is that the best thing to do is to do minor upgrades - 1.8 -> 
1.9.x -> 1.10.x -> 1.11.x (where x is the last patched version of each 
minor version).


Further, at the completion of one Django version, I recommend saving a 
snapshot of your database at that moment, and then starting the next 
upgrade in a new GIT branch :

Git branches:

mycode_django_1.8#  Working version under 1.8

mycode_django_1.9#  Working version under 1.9

mycode_django_1.10  #   ...

mycode_django_1.11  #   ...
 

 


On Monday, September 24, 2018 at 4:08:48 AM UTC-4, Andréas Kühne wrote:
>
> Hi,
>
> My experience is that the best thing to do is to do minor upgrades - 1.8 
> -> 1.9.x -> 1.10.x -> 1.11.x (where x is the last patched version of each 
> minor version). The reason for updating in this fashion, is that when you 
> start the server on each version, you will get warnings about unsupported 
> changes in the upcoming releases.
>
> And of course - having a good test suite will be essential for upgrading 
> successfully. 
>
> When you have done the django upgrade, I would then do the python upgrade 
> (just like others have suggested). Doing both at the same time will just 
> become a huge task
>
> And of course - like others have also stated - django 1.11 is the LTS 
> version, not 2.0. Upgrading to 2.0 is only necessary if you need the 
> features that 2.0 includes (which is mainly changing to a different 
> structure to the urls files and also deprecating python 2).
>
> Good luck!
>
> Regards,
>
> Andréas
>
>
> Den sön 23 sep. 2018 kl 15:56 skrev 'David Brown' via Django users <
> django...@googlegroups.com >:
>
>> I have a large django project built in 1.8 with about 14 apps and a large 
>> amount of dependencies.
>>
>> I already have a good idea about how I'm going to update the 2.7 code to 
>> 3.6 or possibly just make it compatible with both, however, I'm not sure 
>> what is the best practice and most efficient way to refactor/upgrade the 
>> django framework to 2.0 from 1.8. 
>>
>> Bare in mind this thousands of lines of code so efficiency in terms of 
>> work is crucial.
>>
>> Thanks in advance for all suggestions!
>>
>> -- 
>> 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/d6307d12-8920-434b-b5ec-e9b72c0c3443%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/4fe101e6-077f-4ce3-ac76-1f7a03100170%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Creating seperate unique ids within the same table

[bill . torcaso . oxfam]

Hello all,

The previous discussion shows a method that will work.  but I think it has 
disadvantages, and I want to suggest  another approach.

The disadvantage of using a primary key from a table, any table, is that 
you are committing to that table and that primary key for all eternity.  
 this has consequences for migration to another system , for merging in 
data from an external system, among others.

Joel, if I understand your situation, you have a "thing", an individual 
human being, and you need a permanent, unique identifier for that "thing".  
The identifier should not be an implementation detail of your current code, 
but should be robust, sharable, and resilient in the face of evolving 
software.

I faced a similar situation with digital assets that are photos and 
videos.  We share photos and videos across several related sites, but we 
don't want to duplicate the asset for each site.

My solution is to generate a UUID, a Universally Unique IDentifier,  when 
creating the "thing" - see python 3 
at https://docs.python.org/3/library/uuid.html. or python 2 
at https://docs.python.org/2/library/uuid.html.

A Universally Unique IDentifier is guaranteed not to collide with any other 
UUID, and so independent systems can generate one at any time - no need to 
coordinate with a central database or across separate servers.

A UUID is robust in the face of name changes - such as a maiden name 
becoming a married name.

I would recommend a UUID over exposing a primary key, hands down, all the 
time, no exceptions.

--  Bill

-- 
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/8bcbd562-5bb8-49f3-b1ad-1b73ff62d840%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Creating seperate unique ids within the same table

[bill . torcaso . oxfam]

Joel,

I completely agree that UUIDs are not memorable.

I still think you would be well-served to make a UUID the basis for 
uniquely defining a person.  If you want to further add a short name, you 
could make an object class that has a UUID and, say, an 8-digit number.  If 
you assert that the two are unique together, you will get a database-level 
guarantee of uniqueness at creation-time.

This is just an opinion, but I think it an anti-practice to expose a 
primary key for any user-visible purpose.

If you don't like UUID's for your purpose, you might consider the random 
number generator in PyCrypto.

On Monday, October 22, 2018 at 10:20:02 AM UTC-4, Joel wrote:
>
> Thank you Bill. I had a look at UUIDs. One of the important criteria I 
> had was that these IDs should be easily memorable. Unfortunately UUIDs 
> are not memorable, being too long to remember. :( 
>
> Sincerely yours, 
>
> Joel G Mathew 
>
>
> On Mon, 22 Oct 2018 at 19:40, > 
> wrote: 
> > 
> > Hello all, 
> > 
> > The previous discussion shows a method that will work.  but I think it 
> has disadvantages, and I want to suggest  another approach. 
> > 
> > The disadvantage of using a primary key from a table, any table, is that 
> you are committing to that table and that primary key for all eternity.   
> this has consequences for migration to another system , for merging in data 
> from an external system, among others. 
> > 
> > Joel, if I understand your situation, you have a "thing", an individual 
> human being, and you need a permanent, unique identifier for that "thing". 
>  The identifier should not be an implementation detail of your current 
> code, but should be robust, sharable, and resilient in the face of evolving 
> software. 
> > 
> > I faced a similar situation with digital assets that are photos and 
> videos.  We share photos and videos across several related sites, but we 
> don't want to duplicate the asset for each site. 
> > 
> > My solution is to generate a UUID, a Universally Unique IDentifier, 
>  when creating the "thing" - see python 3 at 
> https://docs.python.org/3/library/uuid.html. or python 2 at 
> https://docs.python.org/2/library/uuid.html. 
> > 
> > A Universally Unique IDentifier is guaranteed not to collide with any 
> other UUID, and so independent systems can generate one at any time - no 
> need to coordinate with a central database or across separate servers. 
> > 
> > A UUID is robust in the face of name changes - such as a maiden name 
> becoming a married name. 
> > 
> > I would recommend a UUID over exposing a primary key, hands down, all 
> the time, no exceptions. 
> > 
> > --  Bill 
> > 
> > -- 
> > 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/8bcbd562-5bb8-49f3-b1ad-1b73ff62d840%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/eb95ee38-160e-4acb-b966-9b7f3ddd6c75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Creating seperate unique ids within the same table

[bill . torcaso . oxfam]

Joel said this was a requirement:

One of the important criteria I had was that these IDs should be easily 
memorable. Unfortunately UUIDs are not memorable, being too long to 
remember.
 

A primary key that appears in a URL is just an implementation detail - the 
implementation could change, and still display the equivalent behavior to a 
user.

But when I person has to remember a value, that value is no longer an 
implementation detail.  Again, just my opinion; but that crosses the line.  

-- 
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/b7510c26-ecac-4a68-b7c4-05d5d0e89ad2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running a custom code after the server is up

[bill . torcaso . oxfam]

If I understand your situation, you want to run a management command fairly 
promptly after Django-server reboot, and not again for the duration of the 
server's uptime.

Cron is useful and convenient for repeated tasks.  And it can be made to 
handle once-and-done tasks, if you keep a bit of state somewhere.

There's a lot I don't know about the practical side of your situation, so I 
ask this question from ignorance. Can you use the __init__method of a 
special purpose app in INSTALLED_APPS?  I don't know if the INSTALLED_APPS 
are created during server startup, or only as needed in response to an 
incoming URL.

If each class (or package?) in INSTALLED_APPS gets an object created at 
server-boot time, you can do it within one of your apps.

__init__ can start a separate thread that delays for a specific time 
interval and then does your web-scraping scraping.  __init__() itself 
cannot do the wait, because there is an implicit expectation that 
__init__() finishes in a relatively short period of time.

If the trigger event for starting the web-scraping is something like 
first-visit-to-your-home-page, you could probably use django signals.  But 
I've never used signals and I can't tell you anything more about that.

  ---  Bill

On Friday, November 2, 2018 at 10:35:52 AM UTC-4, Bartosz Gańcza wrote:
>
> Hi everyone!
>
> I am somewhat of a Django beginner and I can't seem to find an easy 
> solution to what I need to do anywhere.
>
> I have a web scraping code I wish to run in the background automatically 
> (once) after the server is up and running. I use Docker to fire up the DB 
> and the web server itself but can't seem to be able to configure it to also 
> fire up the management command I configured that runs the scraping code (I 
> guess using Docker for that is either beyond my current knowledge or is 
> just not possible without using specialised tools like cron, which I don't 
> fully understand).
>
> Is there any way to do something like this in Django itself, without 
> resorting to "ready" function? (I did that at first but it stops the server 
> from running until the code completes and also runs it at least twice)
>
> Best,
> Bartosz
>

-- 
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/db6bf171-d920-4a16-af68-e52b0afffaa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Where to create a Django project

[bill . torcaso . oxfam]

Hope this helps 

When working on an AWS Elastic Beanstalk instance, you can log into the 
system using Secure Shell (SSH), with a key pair.  For EBeanstalk, that key 
pair was either created or selected from existing keys at the time that you 
created the server.

>From there you have a typical TTY session with a shell on a unix-like 
system of some sort. (unless you picked a Windows OS, in which case I can't 
help you)

It's been so long since I worked on an AWS instance outside of EBeanstalk 
that I can't quite remember if the process is the same.


On Friday, November 2, 2018 at 4:30:30 PM UTC-4, KH wrote:
>
> I am new to Django and web development and am having some issues figuring 
> out how to get started. I am following the Django getting started tutorial 
> on their website.
> Where is a Django project supposed to be created? I installed Django into 
> an AWS ec2 instance and was able to run the default startup screen, but I 
> get an error saying I need to change some things in the settings.py file, 
> but I do not know how to open that file for editing if it is in an AWS 
> instance.
>
>

-- 
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/e064fc77-816b-4719-9a56-8a264a7c1ee7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Virtual Groups for learning Django

[bill . torcaso . oxfam]

I hear good things about Django Girls (https://djangogirls.org/).



On Sunday, November 4, 2018 at 8:52:38 AM UTC-5, Expo Tor wrote:
>
> Anyone can recommend any online virtual groups for Django? I mean it 
> should be sth more than online tutorials - where users can come in 
> real-time with their questions.
>

-- 
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/346e144a-6b54-4992-882a-48ac47a5262c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.