date:20170831

Re: Weird date math bug?

2017-08-31 Thread James Schneider

>
I am so embarrassed. Thank you James, spot on.

cheers
L.

No worries. I've stuck my foot in my mouth more than once on this list.

-James

-- 
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/CA%2Be%2BciW3mzcCq%3DhQPOHL%2B6f3nOKU%3D%2B8vKjiAXDe8Sq1HW2QCzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird date math bug?

2017-08-31 Thread Lachlan Musicman

On 1 September 2017 at 14:57, James Schneider 
wrote:

> I'm guessing that ChemoRegime.regime_age() contains line 95.
>
> ChemoRegime defines the stop_date field with null=True and blank=True. I'm
> guessing this is because patients may not have yet stopped treatment, so
> they have no stop_date.
>
> With that in mind, self.stop_date may be None in Python (and Null in the
> DB). Subtracting None from a real datetime.date object is not supported.
>
> Ensure that stop_date has a date value before doing date math with it.
>
> -James
>
>
I am so embarrassed. Thank you James, spot on.

cheers
L.

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

Re: Weird date math bug?

2017-08-31 Thread James Schneider

On Aug 31, 2017 9:44 PM, "Lachlan Musicman"  wrote:

Sorry, let me start again:


Yay, I'm not the only one that does it! Lol...





class ChemoRegime(models.Model):
patient = models.ForeignKey(Patient, on_delete=models.CASCADE)
chemotype = models.ForeignKey(ChemoType, on_delete=models.CASCADE)
start_date = models.DateField(null=True, blank=True)
stop_date = models.DateField(null=True, blank=True)

def regime_age(self):
age = timezone.now().date() - self.stop_date
return age.days






But in the browser:

Exception Type: TypeError
Exception Value:

unsupported operand type(s) for -: 'datetime.date' and 'NoneType'

Exception Location: ./patients/models.py in regime_age, line 95


line 95 is age = timezone.now().date() - self.stop_date


What am I doing wrong?

cheers
L.


I'm guessing that ChemoRegime.regime_age() contains line 95.

ChemoRegime defines the stop_date field with null=True and blank=True. I'm
guessing this is because patients may not have yet stopped treatment, so
they have no stop_date.

With that in mind, self.stop_date may be None in Python (and Null in the
DB). Subtracting None from a real datetime.date object is not supported.

Ensure that stop_date has a date value before doing date math with it.

-James

-- 
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/CA%2Be%2BciXMOY5Mx5C91e0sXasXKa-f5mCga%2BDtf29AtQDaL1sqUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird date math bug?

2017-08-31 Thread Lachlan Musicman

Sorry, let me start again:


Is there a weird date math bug in Django 1.11.4? I say weird because surely
not?

I can't see any tickets in the tracker, but I'm definitely seeing it in
production.

Using postgresql:


models.py

class ChemoType(models.Model):
name = models.CharField(max_length=50, unique=True)

class Patient(models.Model):
chemo_regimes = models.ManyToManyField(
ChemoType,
through='ChemoRegime',
)
def get_latest_chemo(self):
chemo = ChemoRegime.objects.filter(patient=self).latest('stop_date')
return chemo

def get_latest_chemo_age(self):
chemo = ChemoRegime.objects.filter(patient=self).latest('stop_date')
return chemo.regime_age()

class ChemoRegime(models.Model):
patient = models.ForeignKey(Patient, on_delete=models.CASCADE)
chemotype = models.ForeignKey(ChemoType, on_delete=models.CASCADE)
start_date = models.DateField(null=True, blank=True)
stop_date = models.DateField(null=True, blank=True)

def regime_age(self):
age = timezone.now().date() - self.stop_date
return age.days




In django_extension's shell plus:

>>> p = Patient.objects.get(id=1)
>>> p.get_latest_chemo()

>>> p.get_latest_chemo_age()
12
>>> p.get_latest_chemo_age
>
>>> type(p.get_latest_chemo_age())





In the template

  {% for patient in object_list %}

   {{ patient
}}
   {{ patient.get_latest_chemo_age }} ago





But in the browser:

Exception Type: TypeError
Exception Value:

unsupported operand type(s) for -: 'datetime.date' and 'NoneType'

Exception Location: ./patients/models.py in regime_age, line 95


line 95 is age = timezone.now().date() - self.stop_date


What am I doing wrong?

cheers
L.

--
"The antidote to apocalypticism is apocalyptic civics. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

Greg Bloom @greggish https://twitter.com/greggish/status/873177525903609857

-- 
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/CAGBeqiMoZXiwUhL-gL1uPzOw%3DC4JfoDZnfOFs6Qys4HU7RZV%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Weird date math bug?

2017-08-31 Thread Lachlan Musicman

Is there a weird date math bug in Django 1.11.4? I say weird because surely
not?

I can't see any tickets in the tracker, but I'm definitely seeing it in
production.

Using postgresql:


class Patient(models.Model):


--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857

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

Re: A lot of Problems with Migrating (conceptual)

2017-08-31 Thread Alexander Joseph

Thanks Melvyn, good to know. I'll keep that in mind



On Thursday, August 31, 2017 at 9:19:57 AM UTC-6, Melvyn Sopacua wrote:
>
> There are two main principles to remember about Django migrations in early 
> development stage:
>
> 1) Make migrations often and coherent.
>Typically, if you change something about a model, make a migration.
>When you want to cover multiple models in one migration, there should be
>a good reason for it. If you can't think of it, don't.
>
> 2) When the design is flawed, don't add to the problem by creating another
>migration. Instead roll back, remove the migration file(s), alter the
>design and make a new migration.
>
> The second principle is often overlooked and by applying the first, the
> "damage" is minimized.
>
> Rolling back is done by adding a migration number to the `migrate` 
> management
> command and it will roll back to the point including that migration.
>
> Once you freeze the model design, feel free to squash some or all 
> migrations
> into one file if things got a little big.
>
>
> On Wed, Aug 30, 2017 at 12:16 AM, Alexander Joseph  > wrote:
>
>> Thanks James,
>> I'm actually starting over from scratch instead of actually refactoring 
>> so the accounts app is the only real app I have so far. I actually did 
>> delete the database and just apply migrations to the newly created database 
>> and it worked ok. I'd like to get better at fixing these migration problems 
>> though since I'll probably run into a lot of them and wont be able to 
>> delete the database once I have data.
>>
>> Do you think it would have been better to run migrations for the specific 
>> accounts app? I thought it wouldnt matter much since accounts is my only 
>> app I have so far.
>>
>> My new structure so far looks like this
>>
>> business_management/
>> business_management/
>> accounts/
>> migrations/
>> __init__.py
>> admin.py
>> forms.py
>> models.py
>> tests.py
>> views.py
>> static/
>> templates/
>> config/
>> settings/
>> __init__.py
>> base.py
>> local.py
>> production.py
>> __init__.py
>> docs/
>> (developer documentation)
>> requirements/
>> (requirements.txt files)
>> utility/
>> (shell scripts)
>> manage.py
>> .gitignore
>>
>>
>>
>>
>> On Tuesday, August 29, 2017 at 3:35:21 PM UTC-6, James Schneider wrote:
>>>
>>>
>>>
>>> On Tue, Aug 29, 2017 at 7:13 AM, Alexander Joseph <
>>> alexander...@gmail.com> wrote:
>>>
 I'm not specifying the app level, I'm just running "python manage.py 
 makemigrations --settings=config.settings.local"  and  "python 
 manage.py migrate --settings=config.settings.local"
 I'm not modifying the migrations files and I dont have an app with the 
 label of admin, thats just the built-in admin. Thanks

>>>
>>>
>>> I know you were doing a lot of refactoring. Did you rename the accounts 
>>> app after performing an initial migration (applying an old migration with 
>>> the old app name structure)? It sounds like your DB and your migration 
>>> files might be out of sync. If you don't have any production data, I would 
>>> recommend deleting and recreating the entire database, and deleting and 
>>> recreating your migrations so that all the migrations are run in the 
>>> correct order.
>>>
>>> If you do have data you want to keep, then very likely you now have a 
>>> ton of work to do writing custom migrations to sync everything back up 
>>> manually. 
>>>
>>> -James
>>>
>> -- 
>> 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/0686084f-1d5a-4f61-823e-7d84c58f317c%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Melvyn Sopacua
>

-- 
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/7b2eba67-bb19-4ba0-9d3d-7277da32f8be%40googlegroups.com.
For more options, visit

django-channels get the json post on connect

2017-08-31 Thread Samuel Muiruri

I have this in routing.py for django-channels

channel_routing = [
   # Wire up websocket channels to our consumers:
   route("websocket.connect", ws_connect),
   route("websocket.receive", ws_message),
]

and the ws_connect looks like this

@channel_session
def ws_connect(message, key):
# Accept connection
message.reply_channel.send({"accept": True})

and when the page loads this socket connection is made correctly


// Note that the path doesn't matter for routing; any WebSocket
// connection gets bumped over to WebSocket consumers
socket = new WebSocket("ws://" + window.location.host + "/chat/");
socket.onmessage = function(response) {
   console.log(response.data);
}
socket.onopen = function() {
   socket.send({"test":"data"});
}
// Call onopen directly if socket is already open
if (socket.readyState == WebSocket.OPEN) socket.onopen();


I want to start testing if I can have a background process running from 
this, so I set a test json input to socket.send however I haven't found 
anything on the documentation, apologies if I missed it. How to access this 
info in ws_connect it should be in message same way there's request I 
believe.

-- 
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/375ec390-a4fb-4112-a378-3a1d1a56eb6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is some problem in field options 'null'?

2017-08-31 Thread Melvyn Sopacua

The document says to avoid null=True for character fields,
because they both "mean the same thing": there is nothing
in there.

They are however different and this is why Django returns
None:

- Empty character fields are considered a value
- NULL character fields are not

This is important in unique constraints:
Two rows with empty string are forbidden
Two (or more) rows set to NULL are allowed.



On Sat, Aug 26, 2017 at 2:09 PM, Jinwen  wrote:

> I read the document
> 
> about field options 'null'.
>
> It is said that.
>
> If True, Django will store empty values as NULL in the database. Default
>> is False.
>>
>> Avoid using null
>> 
>>  on
>> string-based fields such as CharField
>> 
>>  and TextField
>> .
>> If a string-based field has null=True, that means it has two possible
>> values for “no data”: NULL, and the empty string.
>>
>
> Then I try make a field have "null=True", just save it to database.
>
> like that.
>
> >>> from backend.models import Scrapyd as S
> >>> s = S()
> >>> s.comment
> >>> type(s.comment)
> 
> >>> s.save()
> >>> b  = S.objects.all().last()
> >>> b
> 
> >>> b.comment
> >>> type(b.comment)
> 
>
>
> *What my question is why the value not like the document
> said is
> empty string ''?*
>
> *I am confused.*
>
> --
> 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/1b239340-78d6-4df2-a12d-9531dfe7912d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Melvyn Sopacua

-- 
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/CA%2Bgw1GWiq7jR4ptTLp%2Bj%3DLDboXcKvCuNXL_g8vp6YioqmJuOjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Link to download a file

2017-08-31 Thread giuseppe ricci

Hi guys, I need some help to insert a link to download a file. In a view I 
read data from a csv file and I show them in a table in a template. Under 
the table I need to insert, when there are data, 
a link similar as Download data and when user click it, he download the 
datafile, previously I wrote the same data in a csv file. You can see a 
part of interested view and the template to show data. 
In the code doesn't download anything.

views.py 

listafile = os.listdir('static/dati')

fileok=[]
context={}
i=0
for file in listafile:
inizio=str(file[0:4]).strip()
if inizio==anno:   
fileok.append(file)
elif inizio=='coun':
contaf=str(file[6:10]).strip()
if contaf==anno:
fileok.append(file)
else:
pass #print "File NON trovato", inizio, anno

for nomefile in fileok:
nomedato=str(nomefile[5:-4]).strip()
if nomedato==tipodati:
path2file=str(("static/dati/"+str(nomefile)).strip())
with open(path2file) as f:
for line in f:
riga = line.split(";")
if riga[0]==cciaa:
context[i]=line
i=i+1
#print "context", context

d2 = {  k:v.split(";") for k,v in context.items() }
j=0
datilist={} 
field_names = ['Provincia CCIAA', 'Data Ora', 'Numero REA', 'Forma 
Giuridica', 'Count dati']
f=open('static/tmp/dati.csv', 'w') 
writer = csv.writer(f) #questa definisce la variabile writer usata 
x scrivere i dati nel file csv!!!
writer.writerow(field_names)

while j

Re: trying to create allauth SignupForm subclass for customization....

2017-08-31 Thread Melvyn Sopacua

The answer lies in the fact that you are getting a Django configuration
exception and not an ImportError.

The solution: https://github.com/pennersr/django-allauth/issues/826

The reason:
https://github.com/pennersr/django-allauth/blob/master/allauth/account/forms.py#L197

So, there is an import loop / inheritance problem: Allauth's SignupForm
makes itself a child of your custom form and you're trying to become it's
child.


On Tue, Aug 29, 2017 at 5:13 AM, Alexander Joseph <
alexander.v.jos...@gmail.com> wrote:

> Hello, I'm trying to add some additional fields to the allauth signup form
> (first_name and last_name). I'm thinking the best way to do this is to
> create a allauth SignupForm subclass and add my own fields (very new to
> django so please let me know if I'm going about this wrong)
>
> I added
>
> ACCOUNT_SIGNUP_FORM_CLASS = 'accounts.forms.UserCreateForm'
>
> to my base settings file
>
>
> and here is my accounts.forms.py...
>
> from django.contrib.auth import get_user_model
> from allauth.account.forms import SignupForm
> from django import forms
>
>
> class UserCreateForm(SignupForm):
> class Meta:
> fields = ("first_name", "last_name", "email", "username",
> "password1", "password2")
> model = get_user_model()
>
> def __init__(self, *args, **kwargs):
> super().__init__(*args, **kwargs)
> self.fields["first_name"].label = ''
> self.fields["first_name"].widget.attrs["placeholder"] = "First
> Name"
> self.fields["last_name"].label = ''
> self.fields["last_name"].widget.attrs["placeholder"] = "Last Name"
> self.fields["email"].label = ''
> self.fields["email"].widget.attrs["placeholder"] = "Email"
> self.fields["username"].label = ''
> self.fields["username"].widget.attrs["placeholder"] = "Username"
> self.fields["password1"].label = ''
> self.fields["password1"].widget.attrs["placeholder"] = "Password"
> self.fields["password2"].label = ''
> self.fields["password2"].widget.attrs["placeholder"] = "Confirm
> Password"
>
>
>
> for some reason I keep getting the error ...
>
> django.core.exceptions.ImproperlyConfigured: Error importing form class
> accounts.forms: "cannot import name 'SignupForm'"
>
> Not sure why. Obviously there is a SignupForm in allauth.account.forms.py,
> seen here...
> https://github.com/pennersr/django-allauth/blob/master/
> allauth/account/forms.py
>
> I dont know what I'm doing wrong. Any help you can give is much 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/ea79940e-0549-4ffa-802f-e72214d4ebe2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Melvyn Sopacua

-- 
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/CA%2Bgw1GXd5rekiPZO-c%3DzPK0yyw_L2XKTKv82n6uzrtgKTKK68g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A lot of Problems with Migrating (conceptual)

2017-08-31 Thread Melvyn Sopacua

There are two main principles to remember about Django migrations in early
development stage:

1) Make migrations often and coherent.
   Typically, if you change something about a model, make a migration.
   When you want to cover multiple models in one migration, there should be
   a good reason for it. If you can't think of it, don't.

2) When the design is flawed, don't add to the problem by creating another
   migration. Instead roll back, remove the migration file(s), alter the
   design and make a new migration.

The second principle is often overlooked and by applying the first, the
"damage" is minimized.

Rolling back is done by adding a migration number to the `migrate`
management
command and it will roll back to the point including that migration.

Once you freeze the model design, feel free to squash some or all migrations
into one file if things got a little big.


On Wed, Aug 30, 2017 at 12:16 AM, Alexander Joseph <
alexander.v.jos...@gmail.com> wrote:

> Thanks James,
> I'm actually starting over from scratch instead of actually refactoring so
> the accounts app is the only real app I have so far. I actually did delete
> the database and just apply migrations to the newly created database and it
> worked ok. I'd like to get better at fixing these migration problems though
> since I'll probably run into a lot of them and wont be able to delete the
> database once I have data.
>
> Do you think it would have been better to run migrations for the specific
> accounts app? I thought it wouldnt matter much since accounts is my only
> app I have so far.
>
> My new structure so far looks like this
>
> business_management/
> business_management/
> accounts/
> migrations/
> __init__.py
> admin.py
> forms.py
> models.py
> tests.py
> views.py
> static/
> templates/
> config/
> settings/
> __init__.py
> base.py
> local.py
> production.py
> __init__.py
> docs/
> (developer documentation)
> requirements/
> (requirements.txt files)
> utility/
> (shell scripts)
> manage.py
> .gitignore
>
>
>
>
> On Tuesday, August 29, 2017 at 3:35:21 PM UTC-6, James Schneider wrote:
>>
>>
>>
>> On Tue, Aug 29, 2017 at 7:13 AM, Alexander Joseph > > wrote:
>>
>>> I'm not specifying the app level, I'm just running "python manage.py
>>> makemigrations --settings=config.settings.local"  and  "python
>>> manage.py migrate --settings=config.settings.local"
>>> I'm not modifying the migrations files and I dont have an app with the
>>> label of admin, thats just the built-in admin. Thanks
>>>
>>
>>
>> I know you were doing a lot of refactoring. Did you rename the accounts
>> app after performing an initial migration (applying an old migration with
>> the old app name structure)? It sounds like your DB and your migration
>> files might be out of sync. If you don't have any production data, I would
>> recommend deleting and recreating the entire database, and deleting and
>> recreating your migrations so that all the migrations are run in the
>> correct order.
>>
>> If you do have data you want to keep, then very likely you now have a ton
>> of work to do writing custom migrations to sync everything back up
>> manually.
>>
>> -James
>>
> --
> 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/0686084f-1d5a-4f61-823e-7d84c58f317c%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Melvyn Sopacua

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

Re: Testing file upload via a form?

2017-08-31 Thread Melvyn Sopacua

In the documentation of the test client

it
is all spelled out how to test file uploads.



On Tue, Aug 29, 2017 at 8:48 PM, Derek  wrote:

> (Python 3.5 and Django 1.10)
>
> I am trying to test a Django form that enables a required file upload.
>
> The form is very simple and includes a field that looks like:
>
> upload_file = forms.FileField()
>
> The corresponding test to try and check the upload:
>
> def test_form_validation_with_file(self):
> fake_file = ContentFile(b'''Some file content''')
> fake_file.name = 'fake.xls'
> suf_file = SimpleUploadedFile('suf.xls', b'''this is text''')
> data = {
> 'upload_file': suf_file,
> }
> form = forms.RequestForm(data=data)
> self.assertTrue(form.is_valid())
>
> The form validation fails i.e. it does not seem to recognise that file
> data has been suppplied.
>
> I have also tried with the  "fake_file" for the data but without success.
>
> Any help or pointers appreciated.
>
> Thanks
> Derek
>
> --
> 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/CAF1Wu3OTCbnw4o749YUz-Pa1-Uo9jkGkd1KybB5rSLnp3eAMDQ%
> 40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Melvyn Sopacua

-- 
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/CA%2Bgw1GVt-pwLwdTx_0m2nj-uy0A%3DBQh8L1aeFNnraMCAy%3DP-iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bizarre URL behaviour after deploying

2017-08-31 Thread Melvyn Sopacua

You may have a reverse proxy on port 80 that incorrectly rewrites
/(.*) to / both ways.

On Thu, Aug 31, 2017 at 2:10 PM, Bernd Wechner  wrote:
> Tom,
>
> So I did a quick test now before retiring after all. And I am pulling my
> hair out now. If I restart lighttpd on port 8000 (the last step to apparent
> convergence) it works. I access both development and webserve sites on:
>
> http://127.0.0.1:8000/
>
> with server local browsers (Chrome on the dev server and Lynx on the
> webserver for lack of a desktop). And they both now have links to:
>
> http://127.0.0.1:8000/list/Player
>
> and the link serves properly on both sites!
>
> Aaargh. Simply moving the web server from port 80 to port 8000 and the
> problem went away. I could tear my hair out here. Again, a small step closer
> to pinning a cause, but not much close to understanding the reason. The site
> wants to run on 80 not 8000.
>
> So I guess more empirical tests on the morrow or weekend will include moving
> runserver onto port 80 (after checking my dev box doesn't have something
> listing there already ;-) to see if it develops the problem) and a close
> look at the code to see if I can find any port dependencies?
>
> I call Twilight Zone of this so far.
>
> Remember, this:
>
> http://127.0.0.1/Leaderboards/list/Player
>
> also works consistently on port 80, that is the menu presents that URL from
>
> Players
>
> and it serves that URL albeit it serves all URLS
>
> http://127.0.0.1/whatever/list/Player
>
> identically.
>
> And on port 8000 that menu presents the URL:
>
> http://127.0.0.1:8000/list/Player
>
> and serves it.
>
> The only difference is one config line in lighttpd.conf:
>
> server.port = 80
>
> vs
>
> server.port = 8000
>
> with a a lighttpd restart ("sudo /etc/init.d/lighttpd restart") between.
> Some code paths differ based on port it seems,
>
> I'll go find a wall to bang my head on now ;-).
>
> Regards,
>
> Bernd.
>
>
> 'Tom Evans' via Django users wrote:
>
> On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner 
> wrote:
>> Daniel,
>>
>> Yes, I have deployed, that is the problem in a sense. URLs are clean in
>> dev
>> and suddenly contain an app_name when deployed.
>>
>> Not sure what you mean by configuration? The Django settings are here:
>>
>> https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py
>>
>> The rest of the config is uwsgi under lighttpd, but none of that is likely
>> to impact the appearance of an app_name in my URLs all of a sudden. I
>> don't
>> mind sharing the config files, but it's a distraction I fear.
>
> I think you will be surprised.
>
> I'm surprised your diagnosis doesn't point you at this straight away,
> if the URLs are correct on one site but incorrect on another site, and
> both sites run the exact same python/django code, then the error is
> certainly in the bits that are different.
>
> Cheers
>
> Tom
>
>
> --
> 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/862e89bd-19ab-1a20-9fcc-8f5152eed92d%40gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Melvyn Sopacua

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

Re: Bizarre URL behaviour after deploying

2017-08-31 Thread Bernd Wechner

Tom,

So I did a quick test now before retiring after all. And I am pulling my 
hair out now. If I restart lighttpd on port 8000 (the last step to 
apparent convergence) it works. I access both development and webserve 
sites on:

http://127.0.0.1:8000/

with server local browsers (Chrome on the dev server and Lynx on the 
webserver for lack of a desktop). And they both now have links to:

http://127.0.0.1:8000/list/Player

and the link serves properly on both sites!

Aaargh. Simply moving the web server from port 80 to port 8000 and the 
problem went away. I could tear my hair out here. Again, a small step 
closer to pinning a cause, but not much close to understanding the 
reason. The site wants to run on 80 not 8000.

So I guess more empirical tests on the morrow or weekend will include 
moving runserver onto port 80 (after checking my dev box doesn't have 
something listing there already ;-) to see if it develops the problem) 
and a close look at the code to see if I can find any port dependencies?

I call Twilight Zone of this so far.

Remember, this:

http://127.0.0.1/Leaderboards/list/Player

also works consistently on port 80, that is the menu presents that URL from

Players

and it serves that URL albeit it serves all URLS

http://127.0.0.1/whatever/list/Player

identically.

And on port 8000 that menu presents the URL:

http://127.0.0.1:8000/list/Player

and serves it.

The only difference is one config line in lighttpd.conf:

server.port = 80

vs

server.port = 8000

with a a lighttpd restart ("sudo /etc/init.d/lighttpd restart") between. 
Some code paths differ based on port it seems,

I'll go find a wall to bang my head on now ;-).

Regards,

Bernd.

'Tom Evans' via Django users wrote:

On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner  wrote:
> Daniel,
>
> Yes, I have deployed, that is the problem in a sense. URLs are clean in dev
> and suddenly contain an app_name when deployed.
>
> Not sure what you mean by configuration? The Django settings are here:
>
> https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py
>
> The rest of the config is uwsgi under lighttpd, but none of that is likely
> to impact the appearance of an app_name in my URLs all of a sudden. I don't
> mind sharing the config files, but it's a distraction I fear.

I think you will be surprised.

I'm surprised your diagnosis doesn't point you at this straight away,
if the URLs are correct on one site but incorrect on another site, and
both sites run the exact same python/django code, then the error is
certainly in the bits that are different.

Cheers

Tom

--
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/862e89bd-19ab-1a20-9fcc-8f5152eed92d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bizarre URL behaviour after deploying

2017-08-31 Thread Bernd Wechner

Daniel,

it's a red herring. I agree, that's where I'd suspect the issue lies, 
but I'm still confident it's a red herring. But because I'm stuck even 
the seemingly impossible needs to be revisited I guess. It's hard to 
share everything about a webservers config of course in an email, but 
there are two files of relevance attached if it helps.

lighttp.conf is the lighttp configuration which talks to uwsgi, and 
uwsgi.ini is the uwsgi config that loads the django app and serves it 
(over a unix domain socket to lighttpd). The former is incomplete as it 
has includes (it gets complicated fast I guess), but the relevant 
section is in fact repeated to serve the domain name and the 127.0.0.1 
URL as I was just testing a convergence plan after reading Tom's 
suggestion below (and rather than read up on "or" conditional in 
lighttpd confs I just duplicated the block verbatim for now.

Regards,

Bernd.

Daniel Roseman wrote:

On Thursday, 31 August 2017 10:51:22 UTC+1, Tom Evans wrote:

On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner
 wrote:
> Daniel,
>
> Yes, I have deployed, that is the problem in a sense. URLs are
clean in dev
> and suddenly contain an app_name when deployed.
>
> Not sure what you mean by configuration? The Django settings are
here:
>
>
https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py

>
> The rest of the config is uwsgi under lighttpd, but none of that
is likely
> to impact the appearance of an app_name in my URLs all of a
sudden. I don't
> mind sharing the config files, but it's a distraction I fear.

I think you will be surprised.

I'm surprised your diagnosis doesn't point you at this straight away,
if the URLs are correct on one site but incorrect on another site,
and
both sites run the exact same python/django code, then the error is
certainly in the bits that are different.

Cheers

Tom

Yes. Especially as the problem doesn't seem to be "an app name in my 
urls" but "a random prefix in my urls". We do need to see the lighttpd 
and uwsgi configs.

--
DR.
--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/92ba18a5-4332-493b-a268-928e1f5feabc%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/052f474e-10b4-aa87-3b53-3689d8a058e6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
server.modules = (
"mod_access",
"mod_accesslog",
"mod_alias",
"mod_compress",
"mod_redirect",
"mod_rewrite",
"mod_scgi",
)

# Configure the logs (on USB drive)
accesslog.filename  = "/mnt/passport/log/lighttpd/access.log"
accesslog.format= "%t %h %V %u \"%r\" %>s %b \"%{Referer}i\" 
\"%{User-Agent}i\""
server.errorlog = "/mnt/passport/log/lighttpd/error.log"

# Debugging info sent to the errorlog if enabled
#debug.log-request-header = "enable"
#debug.log-condition-handling = "enable"

server.document-root= "/var/www/html"
server.upload-dirs  = ( "/var/cache/lighttpd/uploads" )
server.pid-file = "/var/run/lighttpd.pid"
server.username = "www-data"
server.groupname= "www-data"
server.port = 8000

index-file.names= ( "index.php", "index.shtml", "index.html", 
"index.lighttpd.html" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

compress.cache-dir  = "/var/cache/lighttpd/compress/"
compress.filetype   = ( "application/javascript", "text/css", 
"text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell

Re: Bizarre URL behaviour after deploying

2017-08-31 Thread Bernd Wechner


Tom,

I will credit you there with stating the obvious in a sense, that I was 
reluctant to accept. Because it seems frankly impossible. But when 
nothing seems possible, we do need to revisit the "apparently" 
impossible, so I pulled a sweet trick and tried identical code in 
devlopment and deployment.


That required an upgrade to Django on development as it had 1.11.2 and 
the webserver deployed on had 1.11.4 so now both have 1.11.4.


Then I tweaked settings.py so it runs the Development settings on the 
Webserver.  Essentially the only bit of varied code between the two 
instances in in settings.py and reads:


   ALLOWED_HOSTS = ["127.0.0.1", "leaderboard.space"]

   import platform
   HOSTNAME = platform.node()

   if HOSTNAME == WEBSERVER:
print("Django settings: Web Server")
   else:
print("Django settings: Development Server")
DEBUG = True

And I see "Django settings: Development Server" echoed by runserver when 
it starts and by uwsgi on the web server.


And so now the only difference remaining is that the dev server uses:

http://127.0.0.1:8000/

and the webserver:

http://leaderboard.space/

Now when I test on both sites, the problem goes away! So you are on the 
money my friend! Now there's a menu link say for listing players and it 
looks respectively like:


http://127.0.0.1:8000/list/Player
http://leaderboard.space/list/Player

Where the latter (without DEBUG = True) links to:

http://leaderboard.space/Leaderboards/list/Player

and that problem goes away just by using DEBUG = True.

Which does not explain it, but pinpoints the cause. I would still love 
to understand how that is not a Django bug and how to lose that URL 
snippet without being in DEBUG mode.


BUT, ain't there always a but, although the menu link lost the app_name 
from the URL It now works on the Development server (i.e. lists players 
in the database) and on the web server dumps with 404:



 Page not found(404)

Request Method: GET
Request URL:http://leaderboard.space/list/Player
Raised by:  Leaderboards.views.view_List

Using the URLconf defined in|CoGs.urls|, Django tried these URL 
patterns, in this order:


1. ^$ [name='home']
2. ^admin/
3. ^login/$ [name='login']
4. ^logout/$ [name='logout']
5. ^fix [name='fix']
6. ^unwind [name='unwind']
7. ^check [name='check']
8. ^rebuild [name='rebuild']
9. ^kill/(?P\w+)/(?P\d+)$ [name='kill']
10. ^list/(?P\w+) [name='list']
11. ^view/(?P\w+)/(?P\d+)$ [name='view']
12. ^add/(?P\w+)$ [name='add']
13. ^edit/(?P\w+)/(?P\d+)$ [name='edit']
14. ^delete/(?P\w+)/(?P\d+)$ [name='delete']
15. ^leaderboards [name='leaderboards']
16. ^json/game/(?P\d+)$ [name='get_game_props']
17. ^json/leaderboards [name='json_leaderboards']
18. ^static\/(?P.*)$

The current path,|Player|, didn't match any of these.

You're seeing this error because you have|DEBUG = True|in your Django 
settings file. Change that to|False|, and Django will display a standard 
404 page.



again I would love to know how that is not a Django bug, because it says 
"http://leaderboard.space/list/Player; does not match 
"^list/(?P\w+) [name='list']" which it does on the Development 
server (understandably, as it does visually here).


Hmmm ... a little closer to seeing what's happening, a little, but not 
much closer to understanding what is happening alas. And now, code is 
identical, only the URL is different, and


So trying to converge even that difference, I access it on the webserver 
(which is a server, and hence lacks GUI, but lynx to the rescue) and I 
can navigate to http://127.0.0.1 and I see the site and click on the 
Players link and get:


 Request Method: GET
Request URL:   http://127.0.0.1/list/Player
 Raised by:Leaderboards.views.view_List

   Using the URLconf defined in CoGs.urls, Django tried these URL 
patterns, in this order:

1. ^$ [name='home']
2. ^admin/
3. ^login/$ [name='login']
4. ^logout/$ [name='logout']
5. ^fix [name='fix']
6. ^unwind [name='unwind']
7. ^check [name='check']
8. ^rebuild [name='rebuild']
9. ^kill/(?P\w+)/(?P\d+)$ [name='kill']
   10. ^list/(?P\w+) [name='list']
   11. ^view/(?P\w+)/(?P\d+)$ [name='view']
   12. ^add/(?P\w+)$ [name='add']
   13. ^edit/(?P\w+)/(?P\d+)$ [name='edit']
   14. ^delete/(?P\w+)/(?P\d+)$ [name='delete']
   15. ^leaderboards [name='leaderboards']
   16. ^json/game/(?P\d+)$ [name='get_game_props']
   17. ^json/leaderboards [name='json_leaderboards']
   18. ^static\/(?P.*)$

   The current path, Player, didn't match any of these.

   You're seeing this error because you have DEBUG = True in your 
Django settings file. Change that to False,

   and Django will display a standard 404 page.

Now runserver is using port 8000 and lighttpd is using port 80, but to 
converge those will have to wait till the morrow I think (I have to 
lighttpd on port 8000 or runserver on port 80) and my guess is no change.


I note that Django knows it's running under runserver because

Re: Bizarre URL behaviour after deploying

2017-08-31 Thread Daniel Roseman

On Thursday, 31 August 2017 10:51:22 UTC+1, Tom Evans wrote:
>
> On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner  > wrote: 
> > Daniel, 
> > 
> > Yes, I have deployed, that is the problem in a sense. URLs are clean in 
> dev 
> > and suddenly contain an app_name when deployed. 
> > 
> > Not sure what you mean by configuration? The Django settings are here: 
> > 
> > https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py 
> > 
> > The rest of the config is uwsgi under lighttpd, but none of that is 
> likely 
> > to impact the appearance of an app_name in my URLs all of a sudden. I 
> don't 
> > mind sharing the config files, but it's a distraction I fear. 
>
> I think you will be surprised. 
>
> I'm surprised your diagnosis doesn't point you at this straight away, 
> if the URLs are correct on one site but incorrect on another site, and 
> both sites run the exact same python/django code, then the error is 
> certainly in the bits that are different. 
>
> Cheers 
>
> Tom 
>


Yes. Especially as the problem doesn't seem to be "an app name in my urls" 
but "a random prefix in my urls". We do need to see the lighttpd and uwsgi 
configs.
--
DR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/92ba18a5-4332-493b-a268-928e1f5feabc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bizarre URL behaviour after deploying

2017-08-31 Thread 'Tom Evans' via Django users

On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner  wrote:
> Daniel,
>
> Yes, I have deployed, that is the problem in a sense. URLs are clean in dev
> and suddenly contain an app_name when deployed.
>
> Not sure what you mean by configuration? The Django settings are here:
>
> https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py
>
> The rest of the config is uwsgi under lighttpd, but none of that is likely
> to impact the appearance of an app_name in my URLs all of a sudden. I don't
> mind sharing the config files, but it's a distraction I fear.

I think you will be surprised.

I'm surprised your diagnosis doesn't point you at this straight away,
if the URLs are correct on one site but incorrect on another site, and
both sites run the exact same python/django code, then the error is
certainly in the bits that are different.

Cheers

Tom

-- 
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/CAFHbX1Lo6RNeWiVJutdL9%2BKNdRmXKNsRO-9nAOcn9vs2xq1%2BMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database router with read replica

2017-08-31 Thread Antonis Christofides

Hi,

When I once faced this problem I used django-multidb-router
. It uses the term "pinning"
for the fact that after a query to the master database it "pins" itself to the
master database, i.e. uses the master database exclusively for the rest of the
request. IIRC it works as you say, with a thread-local variable. It wasn't doing
everything I wanted, and merging my pull requests didn't go fast enough, but I
maintained my own fork which worked fine for the project I was working on.

Even if you decide not to use it, it will give you ideas on how to implement the
things you need.

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com


On 2017-08-30 22:16, Matt Pegler wrote:
> I'm hoping for some advice on how to utilize read replica databases with
> Django.  I searched the django-users archive but didn't find much discussion
> about this.  I also can't find many blog posts or discussion elsewhere.  Do
> people have experience or general advice on using read replicas with Django?
>
> I am hoping to implement a database router that will intelligently use a read
> replica while maintaining consistency despite replica lag.  I have a couple
> things I'd like another opinion on:
>
> First is handling replication lag.  Our read replica typically lags ~20ms
> behind master, so we want to route all queries that occur after a write within
> the same request to the master database.  I believe this can be accomplished
> using a thread local in the database router that is reset after each request
> using a middleware.  Does that seem like a reasonable approach?
>
> Second is handling atomic blocks.  As far as I can tell, Django will not
> automatically route all queries within an atomic block to the same database,
> so this needs to be handled within the router.  Is connection.in_atomic_block
> 
>  a
> public API, or is there a better way to tell if we're within an atomic block?
>
> Thanks,
> Matt
> -- 
> 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/CA%2BSd1We3Yq37fYsZu1rVJcxizty6NNG4q-EeVp83wT7aeuh8pQ%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/0d1682c8-42d8-bd62-2be1-1e74d27eef3b%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bizarre URL behaviour after deploying

2017-08-31 Thread James Schneider

What I want to understand is why this "app" suddenly appears in my URLs and
how I can control it (remove it ideally). But I have looked at urls.py long
enough and scratched my head and not found it. settings.py is right next to
if you need to inspect it.


Out of sheer curiosity, what is the actual href= value in the source code
(ie the actual result of the {% url %} tag resolution)?

I also notice that you are generating a bunch of links via JS, have you
verified that those values are not being polluted somehow?

Do URL resolutions for the admin work correctly?

What about for 'login' and 'logout'? Those two are a few URL's you've
defined with trailing slashes. It shouldn't make a difference, but I'm
shooting in the dark here.

-James

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

Re: get json sent to channels in view

2017-08-31 Thread Andrew Godwin

You want to look for incoming data on the "websocket.receive" channel,
which will call you once per message you send down with the right data.
That's "websocket.connect", which happens after the socket opens but before
data is sent down it.

Andrew

On Wed, Aug 30, 2017 at 10:07 AM, Samuel Muiruri 
wrote:

> I have this javascript code that send data to channels
>
> // Note that the path doesn't matter for routing; any WebSocket
> // connection gets bumped over to WebSocket consumers
> socket = new WebSocket("ws://" + window.location.host + "/chat/");
> socket.onmessage = function(e) {
> alert(e.data);
> }
> socket.onopen = function() {
> socket.send({"test":"data"});
> }
> // Call onopen directly if socket is already open
> if (socket.readyState == WebSocket.OPEN) socket.onopen();
>
> I'm curios how from message I can get the json {"test":"data"}
>
> here's the view
>
> # Connected to websocket.connect
> @channel_session
> def ws_connect(message, key):
> # Accept connection
> message.reply_channel.send({"accept": True})
>
>
> if i try message.content['test'] I get a key error
>
> key = message['test']
>   File "/usr/local/lib/python2.7/dist-packages/channels/message.py", line
> 36, in __getitem__
> return self.content[key]
> KeyError: 'test'
>
>
>
> --
>
> Best Regards,
>
> Samuel Muiruri.
>
> Web Designer | +254 738 940064
>
> --
> 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/CAJZFZXpbC%2BZ9xSWumRVALKMnt29DkTLchUtKBv
> kBJyXBh43nQw%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/CAFwN1uoKYptiSAbwfGnUQ-QNbO-M33%3D%3DVm%3D8pv03Agmfh%3DPrpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird date math bug?

Re: Weird date math bug?

Re: Weird date math bug?

Re: Weird date math bug?

Weird date math bug?

Re: A lot of Problems with Migrating (conceptual)

django-channels get the json post on connect

Re: Is some problem in field options 'null'?

Link to download a file

Re: trying to create allauth SignupForm subclass for customization....

Re: A lot of Problems with Migrating (conceptual)

Re: Testing file upload via a form?

Re: Bizarre URL behaviour after deploying

Re: Bizarre URL behaviour after deploying

Re: Bizarre URL behaviour after deploying

Re: Bizarre URL behaviour after deploying

Re: Bizarre URL behaviour after deploying

Re: Bizarre URL behaviour after deploying

Re: Database router with read replica

Re: Bizarre URL behaviour after deploying

Re: get json sent to channels in view

21 matches

Site Navigation

Mail list logo

Footer information