Re: Login in all pages

[Kristofer Pettijohn]

I think the login decorator may give you what you are trying to do in a much 
easier way: 
https://docs.djangoproject.com/en/1.7/topics/auth/default/#limiting-access-to-logged-in-users
 

Unless I am not understanding your issue. 


From: "Juan Diego Gonzalez"  
To: django-users@googlegroups.com 
Sent: Thursday, February 5, 2015 7:35:09 AM 
Subject: Login in all pages 

Hi, I need to put the django login feature in all pages, I mean, the user will 
be able to login in the reserved area of the web from any public page. 

I have all the implementation done, and it works with a single page, in this 
way: 
url(r'^home/$', magic.views.login, {'template_name':'magic/index.html'}), 

I have put the code in a template, and it works only with home page, that is 
logical. Could anyone help me, please. I doesn't find any documentation. 

May be something like url(r'^*/$', magic.views.login, 
{'template_name':'magic/index.html'}), 

where * means any page. 

Thank you very much. 

Diego. 


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group. 
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com . 
To post to this group, send email to django-users@googlegroups.com . 
Visit this group at http://groups.google.com/group/django-users . 
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d44e8397-4b0a-4056-8f48-908793762ff4%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1686270082.107074.1423185601285.JavaMail.zimbra%40cybernetik.net.
For more options, visit https://groups.google.com/d/optout.

Re: Tests and temp tables

[Larry Martell]

On Thu, Feb 5, 2015 at 3:16 PM, Carl Meyer  wrote:
> On 02/05/2015 11:20 AM, Larry Martell wrote:
>> On Thu, Feb 5, 2015 at 10:53 AM, Carl Meyer  wrote:
>>> TransactionTestCase has been around for quite a long time (since 1.1,
>>> IIRC). It's definitely in 1.5.
>>
>> I thought it was not in 1.5 because I went to
>> https://docs.djangoproject.com/en/1.5/topics/testing/tools/#transactiontestcase
>> and got a 404.
>
> Ah, yeah; I think the docs just moved around.
>
 and so on. I need the temp table to get dropped between each get call.
 The best way to do this is if each is in its own MySQL session. Having
 the table truncated doesn't really accomplish this. I think I will
 have to modify the code to drop the temp table after it's used. I hate
 to muck with working production code to accommodate a test, but I also
 don't want the test branch to have a different code base from the
 production branch. I'll probably go with the former option.
>>>
>>> I agree, I don't think TransactionTestCase will help with this situation.
>>>
>>> I find the production design a bit questionable,
>>
>> Why do you say that? I recently added the temp table for performance.
>> I have a query that was taking over an hour. When I broke it into 2
>> queries using a temp table it then ran in 10 seconds. If I've
>> introduced something bad in my app, I'd really like to know about
>> that.
>
> I don't know if it's bad or not, given your needs, but introducing the
> constraint "every request must run in its own MySQL session which is
> shut down after the request" would give me pause, since reusing
> connections (using the built-in Django connection-reuse feature, which
> isn't in 1.5 yet I don't think, or using an external connection pooler)
> is often a quick and easy performance win. And because having every
> request leave the connection in an unusable state makes testing
> harder/slower, too. It just feels wrong :-)

I changed the main code to drop the temp table. This made the tests
run, and also is much cleaner. Thanks for the impetus to do this.


> I don't know exactly why restructuring the query made it faster.

The main table being selected from is largish  - 38 million rows with
282 columns - and it's joined with 6 other tables.

> In PostgreSQL I would usually use a CTE (WITH clause) to allow the same
> type of query decomposition without needing an actual temp table; not
> sure if MySQL supports those. (I recently reworked an ORM query using
> joins to raw SQL with CTEs and saw a similar many-orders-of-magnitude
> performance improvement, because the version with joins was internally
> generating a result-set that grew with the square of the size of a
> particular table.)

I wasn't familiar with CTEs - I just read up on them. I don't think
MySQL supports those.

> But if the temp table is the only approach that
> works, I would probably prefer to have my production code clean it up to
> make session reuse possible. (Ideally, by encapsulating the creation and
> destruction of the temp table in a database stored procedure, so it
> becomes what it ought to be, a query implementation detail, not
> something that application logic needs to be concerned about.)
>
>>>  but taking it as a
>>> given that it meets your needs adequately and you don't want to change
>>> it, you could also address this problem by simply dropping the temp
>>> table in a tearDown() method, no?
>>
>> A tearDown() method would be run after the test, right? I am sending
>> multiple requests within one test.
>
> Can you restructure your tests to avoid that? The more focused a test
> is, usually the better.
>
> If not, then I think you just need a utility method to destroy the temp
> table, which you either call explicitly from your tests after each
> request, or perhaps build into a subclass of the test client so it's
> automated. Although a bit ugly, I think that's still better than trying
> to reconnect to the database for each test; that'll kill your
> test-running speed. (But I'd still prefer fixing the problem at the source.)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY4c%2BH2WsrEWsaekofznaLomRQkk2ufQjfvUC%2BucQYB2DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

survey Site

[sum abiut]

Hi,
I am planning to build a survey site using django just wondering if django
is the best option to get survey done.

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAPCf-y6cVYRbr3r%2BS6i%2BkKQVa7uatkoFDhd8qAdjaPd3j84gMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tests and temp tables

[Carl Meyer]

On 02/05/2015 11:20 AM, Larry Martell wrote:
> On Thu, Feb 5, 2015 at 10:53 AM, Carl Meyer  wrote:
>> TransactionTestCase has been around for quite a long time (since 1.1,
>> IIRC). It's definitely in 1.5.
> 
> I thought it was not in 1.5 because I went to
> https://docs.djangoproject.com/en/1.5/topics/testing/tools/#transactiontestcase
> and got a 404.

Ah, yeah; I think the docs just moved around.

>>> and so on. I need the temp table to get dropped between each get call.
>>> The best way to do this is if each is in its own MySQL session. Having
>>> the table truncated doesn't really accomplish this. I think I will
>>> have to modify the code to drop the temp table after it's used. I hate
>>> to muck with working production code to accommodate a test, but I also
>>> don't want the test branch to have a different code base from the
>>> production branch. I'll probably go with the former option.
>>
>> I agree, I don't think TransactionTestCase will help with this situation.
>>
>> I find the production design a bit questionable,
> 
> Why do you say that? I recently added the temp table for performance.
> I have a query that was taking over an hour. When I broke it into 2
> queries using a temp table it then ran in 10 seconds. If I've
> introduced something bad in my app, I'd really like to know about
> that.

I don't know if it's bad or not, given your needs, but introducing the
constraint "every request must run in its own MySQL session which is
shut down after the request" would give me pause, since reusing
connections (using the built-in Django connection-reuse feature, which
isn't in 1.5 yet I don't think, or using an external connection pooler)
is often a quick and easy performance win. And because having every
request leave the connection in an unusable state makes testing
harder/slower, too. It just feels wrong :-)

I don't know exactly why restructuring the query made it faster. In
PostgreSQL I would usually use a CTE (WITH clause) to allow the same
type of query decomposition without needing an actual temp table; not
sure if MySQL supports those. (I recently reworked an ORM query using
joins to raw SQL with CTEs and saw a similar many-orders-of-magnitude
performance improvement, because the version with joins was internally
generating a result-set that grew with the square of the size of a
particular table.) But if the temp table is the only approach that
works, I would probably prefer to have my production code clean it up to
make session reuse possible. (Ideally, by encapsulating the creation and
destruction of the temp table in a database stored procedure, so it
becomes what it ought to be, a query implementation detail, not
something that application logic needs to be concerned about.)

>>  but taking it as a
>> given that it meets your needs adequately and you don't want to change
>> it, you could also address this problem by simply dropping the temp
>> table in a tearDown() method, no?
> 
> A tearDown() method would be run after the test, right? I am sending
> multiple requests within one test.

Can you restructure your tests to avoid that? The more focused a test
is, usually the better.

If not, then I think you just need a utility method to destroy the temp
table, which you either call explicitly from your tests after each
request, or perhaps build into a subclass of the test client so it's
automated. Although a bit ugly, I think that's still better than trying
to reconnect to the database for each test; that'll kill your
test-running speed. (But I'd still prefer fixing the problem at the source.)

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: how to access json data value(s) returned back to django view from 'GET' request to an api

[Larry Martell]

On Thu, Feb 5, 2015 at 2:10 PM, Henry Versemann  wrote:
> I have a django view (django v. 1.7 ; python v. 2.7.8) which currently and
> successfully sends a request to an api, and receives a good response back.
> I'm sending and receiving using the 'requests' library (v. 2.4.3). Now in
> addition to sending the raw response data back in an HttpResponse I would
> also like to strip out some of the data and create a summary report of it,
> to also send back in my HttpResponse.
>
> I can see the good response data from the request in my command prompt
> window, and it contains a list of items inside of the object to which I've
> assigned the response data. So my question is how do I get at the list of
> items that has been returned back to me as well as all of the data
> (key/value pairs) contained in each list item?
>
> I'm sure there must be some kind of conversion process that I have to run
> the raw response data through. I just haven't out what it is yet.
>
> I've never tried to do this before, from within a django view. If I were
> trying to do this on the client side I would use something like this:
>
>   mydata = jQuery.parseJSON(data);
>
> to make the data accessible, but never having done anything like this before
> on the server side I haven't found anything yet that's been useful or has
> worked.
>
> I would appreciate any help anyone can offer, while I continue to search for
> an answer.

See: https://docs.python.org/3.3/library/json.html

e.g.:

import json
jsonIn = json.loads(request.POST['json_content'])

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY4cV8ion7%3DY6e_nmCvzdTF7VCejA%2BCDRvx_JUZoJ%3D_HMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

how to access json data value(s) returned back to django view from 'GET' request to an api

[Henry Versemann]

I have a django view (django v. 1.7 ; python v. 2.7.8) which currently and 
successfully sends a request to an api, and receives a good response back. 
I'm sending and receiving using the 'requests' library (v. 2.4.3). Now in 
addition to sending the raw response data back in an HttpResponse I would 
also like to strip out some of the data and create a summary report of it, 
to also send back in my HttpResponse.

I can see the good response data from the request in my command prompt 
window, and it contains a list of items inside of the object to which I've 
assigned the response data. So my question is how do I get at the list of 
items that has been returned back to me as well as all of the data 
(key/value pairs) contained in each list item?

I'm sure there must be some kind of conversion process that I have to run 
the raw response data through. I just haven't out what it is yet.

I've never tried to do this before, from within a django view. If I were 
trying to do this on the client side I would use something like this:

  mydata = jQuery.parseJSON(data);

to make the data accessible, but never having done anything like this 
before  on the server side I haven't found anything yet that's been useful 
or has worked.

I would appreciate any help anyone can offer, while I continue to search 
for an answer.

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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8f661a72-2b2f-4836-a8ee-aac687f10e13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tests and temp tables

[Larry Martell]

On Thu, Feb 5, 2015 at 10:53 AM, Carl Meyer  wrote:
> Hi Larry,
>
> On 02/05/2015 06:57 AM, Larry Martell wrote:
>> On Thu, Feb 5, 2015 at 7:29 AM, Jani Tiainen  wrote:
>>> On Tue, 3 Feb 2015 19:38:31 -0500
>>> Larry Martell  wrote:
>>>
 I have a django app that uses a temp table. In the real world this is
 no issue, as each invocation of the app runs in its own MySQL session
 so there cannot be any conflict with the temp tables. But in my tests
 there are multiple requests sent, and apparently they are all in the
 same session, as on the second request I get an error because the temp
 table already exists. I tried logging out between requests, and I
 tried creating a new Client instance for each request, but I still got
 the error. Then I tried deleting the Client object, but I got Client
 object has no attribute __del__.

 What I can do so that each request in a test has its own MySQL session?
>>>
>>>
>>> Instead of Django standard TestCase (which internally wraps all in single 
>>> transaction and makes transactions as a no-op), you should use 
>>> TransactionalTestCase.
>>>
>>> https://docs.djangoproject.com/en/1.7/topics/testing/tools/#transactiontestcase
>>
>> Thanks for the reply Jani. We're using 1.5 and I don't think this is
>> available in that version. We'll probably be moving to 1.6 soon
>> though, and it is there.
>
> TransactionTestCase has been around for quite a long time (since 1.1,
> IIRC). It's definitely in 1.5.

I thought it was not in 1.5 because I went to
https://docs.djangoproject.com/en/1.5/topics/testing/tools/#transactiontestcase
and got a 404.

>> But I'm not sure how this will be useful to
>> me. The docs say "A TransactionTestCase resets the database after the
>> test runs by truncating all tables."  My test code is something like
>> this:
>>
>> # load test data
>> # login
>> response = self.client.get('...')
>> self.assertEqual(response.status_code, 200)
>> # collect results
>>
>> response = self.client.get('...')
>> self.assertEqual(response.status_code, 200)
>> # collect results
>>
>> and so on. I need the temp table to get dropped between each get call.
>> The best way to do this is if each is in its own MySQL session. Having
>> the table truncated doesn't really accomplish this. I think I will
>> have to modify the code to drop the temp table after it's used. I hate
>> to muck with working production code to accommodate a test, but I also
>> don't want the test branch to have a different code base from the
>> production branch. I'll probably go with the former option.
>
> I agree, I don't think TransactionTestCase will help with this situation.
>
> I find the production design a bit questionable,

Why do you say that? I recently added the temp table for performance.
I have a query that was taking over an hour. When I broke it into 2
queries using a temp table it then ran in 10 seconds. If I've
introduced something bad in my app, I'd really like to know about
that.

>  but taking it as a
> given that it meets your needs adequately and you don't want to change
> it, you could also address this problem by simply dropping the temp
> table in a tearDown() method, no?

A tearDown() method would be run after the test, right? I am sending
multiple requests within one test.

Thanks!
-larry

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

Re: subdomains and HOST in settings.py?

[Guilherme Leal]

Lets aproach this from other angle. What effect this would have on your
app? Despite the fact that are different subdomains, there are other logic
that the app implements based on the subdomain?

Em Thu Feb 05 2015 at 14:18:48, Abraham Varricatt <
abraham.varric...@googlemail.com> escreveu:

> It's more like, if a user tried logging into http://www.example.com he
> would be redirected to http://.example.com.
>
> Any simple ways to enforce this? Visually, the 2 links would be identical
> to the end-user (barring their login name somewhere)
>
> -Abraham V.
>
>
> On Thu, Feb 5, 2015 at 9:37 PM, Guilherme Leal 
> wrote:
>
>> I've made something similar. The app had multiple databases, and the
>> database that was connected was based on the subdomain of the request.
>> Basically, if you tried to log in with "http://test.exemple.com;, the
>> database that would be used would be "test".
>>
>> The key to this feature was that the auth was on a separate db, and on
>> that db existed a profile table that indicates on wich database every user
>> would login.
>>
>> I think that it's kinda the inverse from what you need.
>>
>> Em Thu Feb 05 2015 at 13:59:34, mdj  escreveu:
>>
>>> If you're talking about ALLOWED_HOSTS, make sure you use something like
>>> ALLOWED_HOSTS = ['.example.com']. The dot is significant.
>>>
>>> You will also need to set SESSION_COOKIE_DOMAIN = '.example.com' so
>>> cookies work across subdomains.
>>>
>>>
>>> On Thursday, February 5, 2015 at 4:12:24 AM UTC-8, Abraham Varricatt
>>> wrote:

 Hello,

 I'm trying to implement custom subdomains on a customer site and am
 having trouble understanding how the HOST option in settings.py works. The
 requirement is that if a user logs in, they should see their own username
 as the subdomain. So for example if we have 3 users - mark, alice and bob.
 Now, if mark is logged in, he should interact with
 http://mark.example.com . If alice is logged in, she should access
 http://alice.example.com and so on.

 I've implemented this via custom middleware. What the middleware does
 is; if whoever is accessing the site is a logged in user, check if they are
 accessing the site via their respective subdomain entry. If not, prepend
 their username to their request and issue a redirect to their web-browser.
 The idea here is that if a logged in user (mark) tried to access
 http://www.example.com/food/apple then he would be redirected to
 http://mark.example.com/food/apple

 This works half-way. My users are able to login to the site, but for
 some cases, where I need to call 3rd party APIs (and some jquery), things
 aren't working as they should. It's kindof difficult to describe the issue,
 but what I discovered is that in my settings.py file, if I set HOST=
 mark.example.com , then the site works perfectly for user mark, but is
 partly broken for the others. If I set HOST=alice.example.com, things
 work perfectly for alice, but not anyone else.

 Does anyone have any good explanation for this behavior? Or should I be
 trying a different approach? We're running django 1.5.

 Puzzled,
 Abraham V.



  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-users@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/5d71e4bd-06ac-4d83-9d4a-a4e809d5024b%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-users/NIEINxJQnM0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> django-users+unsubscr...@googlegroups.com.
>
>
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/CAOs3Lp568ax2avSL5n3sUTLkJh0jBndcFYWstu_Pa8cpLBqkuw%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
> 

Re: subdomains and HOST in settings.py?

[Abraham Varricatt]

It's more like, if a user tried logging into http://www.example.com he
would be redirected to http://.example.com.

Any simple ways to enforce this? Visually, the 2 links would be identical
to the end-user (barring their login name somewhere)

-Abraham V.


On Thu, Feb 5, 2015 at 9:37 PM, Guilherme Leal  wrote:

> I've made something similar. The app had multiple databases, and the
> database that was connected was based on the subdomain of the request.
> Basically, if you tried to log in with "http://test.exemple.com;, the
> database that would be used would be "test".
>
> The key to this feature was that the auth was on a separate db, and on
> that db existed a profile table that indicates on wich database every user
> would login.
>
> I think that it's kinda the inverse from what you need.
>
> Em Thu Feb 05 2015 at 13:59:34, mdj  escreveu:
>
>> If you're talking about ALLOWED_HOSTS, make sure you use something like
>> ALLOWED_HOSTS = ['.example.com']. The dot is significant.
>>
>> You will also need to set SESSION_COOKIE_DOMAIN = '.example.com' so
>> cookies work across subdomains.
>>
>>
>> On Thursday, February 5, 2015 at 4:12:24 AM UTC-8, Abraham Varricatt
>> wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to implement custom subdomains on a customer site and am
>>> having trouble understanding how the HOST option in settings.py works. The
>>> requirement is that if a user logs in, they should see their own username
>>> as the subdomain. So for example if we have 3 users - mark, alice and bob.
>>> Now, if mark is logged in, he should interact with
>>> http://mark.example.com . If alice is logged in, she should access
>>> http://alice.example.com and so on.
>>>
>>> I've implemented this via custom middleware. What the middleware does
>>> is; if whoever is accessing the site is a logged in user, check if they are
>>> accessing the site via their respective subdomain entry. If not, prepend
>>> their username to their request and issue a redirect to their web-browser.
>>> The idea here is that if a logged in user (mark) tried to access
>>> http://www.example.com/food/apple then he would be redirected to
>>> http://mark.example.com/food/apple
>>>
>>> This works half-way. My users are able to login to the site, but for
>>> some cases, where I need to call 3rd party APIs (and some jquery), things
>>> aren't working as they should. It's kindof difficult to describe the issue,
>>> but what I discovered is that in my settings.py file, if I set HOST=
>>> mark.example.com , then the site works perfectly for user mark, but is
>>> partly broken for the others. If I set HOST=alice.example.com, things
>>> work perfectly for alice, but not anyone else.
>>>
>>> Does anyone have any good explanation for this behavior? Or should I be
>>> trying a different approach? We're running django 1.5.
>>>
>>> Puzzled,
>>> Abraham V.
>>>
>>>
>>>
>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/5d71e4bd-06ac-4d83-9d4a-a4e809d5024b%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/NIEINxJQnM0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAOs3Lp568ax2avSL5n3sUTLkJh0jBndcFYWstu_Pa8cpLBqkuw%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 

Re: subdomains and HOST in settings.py?

[Guilherme Leal]

I've made something similar. The app had multiple databases, and the
database that was connected was based on the subdomain of the request.
Basically, if you tried to log in with "http://test.exemple.com;, the
database that would be used would be "test".

The key to this feature was that the auth was on a separate db, and on that
db existed a profile table that indicates on wich database every user would
login.

I think that it's kinda the inverse from what you need.

Em Thu Feb 05 2015 at 13:59:34, mdj  escreveu:

> If you're talking about ALLOWED_HOSTS, make sure you use something like
> ALLOWED_HOSTS = ['.example.com']. The dot is significant.
>
> You will also need to set SESSION_COOKIE_DOMAIN = '.example.com' so
> cookies work across subdomains.
>
>
> On Thursday, February 5, 2015 at 4:12:24 AM UTC-8, Abraham Varricatt wrote:
>>
>> Hello,
>>
>> I'm trying to implement custom subdomains on a customer site and am
>> having trouble understanding how the HOST option in settings.py works. The
>> requirement is that if a user logs in, they should see their own username
>> as the subdomain. So for example if we have 3 users - mark, alice and bob.
>> Now, if mark is logged in, he should interact with
>> http://mark.example.com . If alice is logged in, she should access
>> http://alice.example.com and so on.
>>
>> I've implemented this via custom middleware. What the middleware does is;
>> if whoever is accessing the site is a logged in user, check if they are
>> accessing the site via their respective subdomain entry. If not, prepend
>> their username to their request and issue a redirect to their web-browser.
>> The idea here is that if a logged in user (mark) tried to access
>> http://www.example.com/food/apple then he would be redirected to
>> http://mark.example.com/food/apple
>>
>> This works half-way. My users are able to login to the site, but for some
>> cases, where I need to call 3rd party APIs (and some jquery), things aren't
>> working as they should. It's kindof difficult to describe the issue, but
>> what I discovered is that in my settings.py file, if I set HOST=
>> mark.example.com , then the site works perfectly for user mark, but is
>> partly broken for the others. If I set HOST=alice.example.com, things
>> work perfectly for alice, but not anyone else.
>>
>> Does anyone have any good explanation for this behavior? Or should I be
>> trying a different approach? We're running django 1.5.
>>
>> Puzzled,
>> Abraham V.
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/5d71e4bd-06ac-4d83-9d4a-a4e809d5024b%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAOs3Lp568ax2avSL5n3sUTLkJh0jBndcFYWstu_Pa8cpLBqkuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: subdomains and HOST in settings.py?

[mdj]

If you're talking about ALLOWED_HOSTS, make sure you use something like 
ALLOWED_HOSTS = ['.example.com']. The dot is significant.

You will also need to set SESSION_COOKIE_DOMAIN = '.example.com' so cookies 
work across subdomains.

On Thursday, February 5, 2015 at 4:12:24 AM UTC-8, Abraham Varricatt wrote:
>
> Hello,
>
> I'm trying to implement custom subdomains on a customer site and am having 
> trouble understanding how the HOST option in settings.py works. The 
> requirement is that if a user logs in, they should see their own username 
> as the subdomain. So for example if we have 3 users - mark, alice and bob. 
> Now, if mark is logged in, he should interact with http://mark.example.com 
> . If alice is logged in, she should access http://alice.example.com and 
> so on. 
>
> I've implemented this via custom middleware. What the middleware does is; 
> if whoever is accessing the site is a logged in user, check if they are 
> accessing the site via their respective subdomain entry. If not, prepend 
> their username to their request and issue a redirect to their web-browser. 
> The idea here is that if a logged in user (mark) tried to access 
> http://www.example.com/food/apple then he would be redirected to 
> http://mark.example.com/food/apple
>
> This works half-way. My users are able to login to the site, but for some 
> cases, where I need to call 3rd party APIs (and some jquery), things aren't 
> working as they should. It's kindof difficult to describe the issue, but 
> what I discovered is that in my settings.py file, if I set HOST=
> mark.example.com , then the site works perfectly for user mark, but is 
> partly broken for the others. If I set HOST=alice.example.com, things 
> work perfectly for alice, but not anyone else. 
>
> Does anyone have any good explanation for this behavior? Or should I be 
> trying a different approach? We're running django 1.5.
>
> Puzzled,
> Abraham V.
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5d71e4bd-06ac-4d83-9d4a-a4e809d5024b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

the source code in utils.functional about lazy function

[Fred Zhang]

Recently I am learning about django source code from utils folder.
But about* functional* file, I don't know the meaning of lazy function.
Can anyboby help me to explain about the meaning about it？
Thanks



The code:


class Promise(object):
"""
This is just a base class for the proxy class created in
the closure of the lazy function. It can be used to recognize
promises in code.
"""
pass




def lazy(func, *resultclasses):
"""
Turns any callable into a lazy evaluated callable. You need to give 
result
classes or types -- at least one is needed so that the automatic 
forcing of
the lazy evaluation code is triggered. Results are not memoized; the
function is evaluated on every access.
"""
 
 '''
 @functools.total_ordering 
 Given a class defining one or more rich comparison ordering methods, 
 this class decorator supplies the rest. 
 This simplifies the effort involved in specifying all of the possible rich 
comparison operations:


 The class must define one of __lt__(), __le__(), __gt__(), or __ge__(). 
 In addition, the class should supply an __eq__() method.


 For example:


 @total_ordering
 class Student:
 def _is_valid_operand(self, other):
 return (hasattr(other, "lastname") and
 hasattr(other, "firstname"))
 def __eq__(self, other):
 if not self._is_valid_operand(other):
 return NotImplemented
 return ((self.lastname.lower(), self.firstname.lower()) ==
 (other.lastname.lower(), other.firstname.lower()))
 def __lt__(self, other):
 if not self._is_valid_operand(other):
 return NotImplemented
 return ((self.lastname.lower(), self.firstname.lower()) <
 (other.lastname.lower(), other.firstname.lower()))






 '''
@total_ordering
class __proxy__(Promise):
"""
Encapsulate a function call and act as a proxy for methods that are
called on the result of that function. The function is not evaluated
until one of the methods on the result is called.
"""
__dispatch = None


def __init__(self, args, kw):
self.__args = args
self.__kw = kw
if self.__dispatch is None:
self.__prepare_class__()


def __reduce__(self):
return (
_lazy_proxy_unpickle,
(func, self.__args, self.__kw) + resultclasses
)


@classmethod
def __prepare_class__(cls):
cls.__dispatch = {}
for resultclass in resultclasses:
cls.__dispatch[resultclass] = {}
for type_ in reversed(resultclass.mro()):
for (k, v) in type_.__dict__.items():
# All __promise__ return the same wrapper method, 
but
# they also do setup, inserting the method into the
# dispatch dict.
meth = cls.__promise__(resultclass, k, v)
if hasattr(cls, k):
continue
setattr(cls, k, meth)
cls._delegate_bytes = bytes in resultclasses
cls._delegate_text = six.text_type in resultclasses
assert not (cls._delegate_bytes and cls._delegate_text), "Cannot 
call lazy() with both bytes and text return types."
if cls._delegate_text:
if six.PY3:
cls.__str__ = cls.__text_cast
else:
cls.__unicode__ = cls.__text_cast
elif cls._delegate_bytes:
if six.PY3:
cls.__bytes__ = cls.__bytes_cast
else:
cls.__str__ = cls.__bytes_cast


@classmethod
def __promise__(cls, klass, funcname, method):
# Builds a wrapper around some magic method and registers that
# magic method for the given type and method name.
def __wrapper__(self, *args, **kw):
# Automatically triggers the evaluation of a lazy value and
# applies the given magic method of the result type.
res = func(*self.__args, **self.__kw)
for t in type(res).mro():
if t in self.__dispatch:
return self.__dispatch[t][funcname](res, *args, **kw
)
raise TypeError("Lazy object returned unexpected type.")


if klass not in cls.__dispatch:
cls.__dispatch[klass] = {}
cls.__dispatch[klass][funcname] = method
return __wrapper__


def __text_cast(self):
return func(*self.__args, **self.__kw)


def __bytes_cast(self):
return bytes(func(*self.__args, **self.__kw))


def __cast(self):
if self._delegate_bytes:
return self.__bytes_cast()
elif self._delegate_text:
return self.__text_cast()
else:
return func(*self.__args, **self.__kw)

Re: subdomains and HOST in settings.py?

[Abraham Varricatt]

@Guilherme Leal,

Yes, that's correct. Do you have any ideas?

-Abraham V.


On Thu, Feb 5, 2015 at 9:15 PM, Guilherme Leal  wrote:

> Basiacally, what you want to do is change the request subdomain based on
> the user that logs on to the app.
>
> Ex: the url that hosts the login form (or whatever it is) is like "
> http://exemple.com/login;. After the user correctly logs in, every
> request will be made to de url "http://.exemple.com".
>
> Is that correct?
>
> Em quinta-feira, 5 de fevereiro de 2015 11:19:19 UTC-2, Vijay Khemlani
> escreveu:
>>
>> I'm not following, in the Django settings there is no "HOST" entry (other
>> than the one used to connect to the database)
>>
>> https://docs.djangoproject.com/en/1.7/ref/settings/
>>
>> If you're talking about "ALLOWED_HOSTS", then that one is only a
>> whitelist of allowed domains.
>>
>> Try and describe your problem with more detail, What error are you
>> getting? What problem with JQuery are you having?
>>
>> On Thu, Feb 5, 2015 at 9:48 AM, Abraham Varricatt <
>> abraham@googlemail.com> wrote:
>>
>>> Ok, I think I goofed up asking the question here. I noticed that there
>>> was a HOST setting defined in the django documentation and assumed it was
>>> the same thing, but some more code investigation, reveals otherwise.
>>>
>>> But I *am* running into a tangential issue. I mentioned that if I set
>>> the value of HOST=alice.example.com that the site works for alice?
>>> Well, I did a bit of middleware tweaking so that the value of settings.HOST
>>> would get changed depending on the user, but that doesn't seem to have
>>> helped. :(
>>>
>>> -Abraham V.
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-users/52349660-aaa1-44ac-9c5f-d3b8fa28a230%
>>> 40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/NIEINxJQnM0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/996bdee2-8306-4c3f-89f4-d9c93deba248%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CADeSw2y3KE6gDvoADaQWSp2PW_8L29XQDbGjOF8vP0%3Dc-%2BBzFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tests and temp tables

[Carl Meyer]

Hi Larry,

On 02/05/2015 06:57 AM, Larry Martell wrote:
> On Thu, Feb 5, 2015 at 7:29 AM, Jani Tiainen  wrote:
>> On Tue, 3 Feb 2015 19:38:31 -0500
>> Larry Martell  wrote:
>>
>>> I have a django app that uses a temp table. In the real world this is
>>> no issue, as each invocation of the app runs in its own MySQL session
>>> so there cannot be any conflict with the temp tables. But in my tests
>>> there are multiple requests sent, and apparently they are all in the
>>> same session, as on the second request I get an error because the temp
>>> table already exists. I tried logging out between requests, and I
>>> tried creating a new Client instance for each request, but I still got
>>> the error. Then I tried deleting the Client object, but I got Client
>>> object has no attribute __del__.
>>>
>>> What I can do so that each request in a test has its own MySQL session?
>>
>>
>> Instead of Django standard TestCase (which internally wraps all in single 
>> transaction and makes transactions as a no-op), you should use 
>> TransactionalTestCase.
>>
>> https://docs.djangoproject.com/en/1.7/topics/testing/tools/#transactiontestcase
> 
> Thanks for the reply Jani. We're using 1.5 and I don't think this is
> available in that version. We'll probably be moving to 1.6 soon
> though, and it is there.

TransactionTestCase has been around for quite a long time (since 1.1,
IIRC). It's definitely in 1.5.

> But I'm not sure how this will be useful to
> me. The docs say "A TransactionTestCase resets the database after the
> test runs by truncating all tables."  My test code is something like
> this:
> 
> # load test data
> # login
> response = self.client.get('...')
> self.assertEqual(response.status_code, 200)
> # collect results
> 
> response = self.client.get('...')
> self.assertEqual(response.status_code, 200)
> # collect results
> 
> and so on. I need the temp table to get dropped between each get call.
> The best way to do this is if each is in its own MySQL session. Having
> the table truncated doesn't really accomplish this. I think I will
> have to modify the code to drop the temp table after it's used. I hate
> to muck with working production code to accommodate a test, but I also
> don't want the test branch to have a different code base from the
> production branch. I'll probably go with the former option.

I agree, I don't think TransactionTestCase will help with this situation.

I find the production design a bit questionable, but taking it as a
given that it meets your needs adequately and you don't want to change
it, you could also address this problem by simply dropping the temp
table in a tearDown() method, no?

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: subdomains and HOST in settings.py?

[Guilherme Leal]

Basiacally, what you want to do is change the request subdomain based on 
the user that logs on to the app. 

Ex: the url that hosts the login form (or whatever it is) is like 
"http://exemple.com/login;. After the user correctly logs in, every request 
will be made to de url "http://.exemple.com".

Is that correct?

Em quinta-feira, 5 de fevereiro de 2015 11:19:19 UTC-2, Vijay Khemlani 
escreveu:
>
> I'm not following, in the Django settings there is no "HOST" entry (other 
> than the one used to connect to the database)
>
> https://docs.djangoproject.com/en/1.7/ref/settings/
>
> If you're talking about "ALLOWED_HOSTS", then that one is only a whitelist 
> of allowed domains.
>
> Try and describe your problem with more detail, What error are you 
> getting? What problem with JQuery are you having?
>
> On Thu, Feb 5, 2015 at 9:48 AM, Abraham Varricatt <
> abraham@googlemail.com > wrote:
>
>> Ok, I think I goofed up asking the question here. I noticed that there 
>> was a HOST setting defined in the django documentation and assumed it was 
>> the same thing, but some more code investigation, reveals otherwise. 
>>
>> But I *am* running into a tangential issue. I mentioned that if I set the 
>> value of HOST=alice.example.com that the site works for alice? Well, I 
>> did a bit of middleware tweaking so that the value of settings.HOST would 
>> get changed depending on the user, but that doesn't seem to have helped. :(
>>
>> -Abraham V.
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/52349660-aaa1-44ac-9c5f-d3b8fa28a230%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/996bdee2-8306-4c3f-89f4-d9c93deba248%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

oracle syncdb crashes while setting column to NULL when it already is NULL

[Joris Benschop]

hi

I'm not sure if this is a dev question or it should be posted here. 
Probably I did something dumb, so I hope you can help me doscover what that 
is:

I'm trying to syncdb to an empty Oracle DB. Many tables, triggers and 
sequences are made but then this:
--
...
Synchronizing apps without migrations:
  Creating tables...
Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0002_remove_content_type_name...DEBUG ALTER TABLE 
"DJANGO_CONTENT_TYPE" MODIFY "NAME" NULL; (params [])
DEBUG (0.055) QUERY = u'ALTER TABLE "DJANGO_CONTENT_TYPE" MODIFY "NAME" 
NULL' - PARAMS = (); args=[]
Traceback (most recent call last):
...
...
django.db.utils.DatabaseError: ORA-01451: column to be modified to NULL 
cannot be modified to NULL
--

Indeed if I run this in oracle directly:
ALTER TABLE "DJANGO_CONTENT_TYPE" MODIFY "NAME" NULL;
I get the same error: you cannot change a NULL column into NULL

I don't understand why django wants to alter a column name of a table it 
just made a few seconds before, but still. 
What seems to happen is that it changes a column to NULL, but because it 
already is NULL, the statement fails.
Workaround is to manually set: 
ALTER TABLE "DJANGO_CONTENT_TYPE" MODIFY ("NAME" NOT NULL);
Then run syncdb again and the error is gone.

I can see this is sillyness of oracle, but theres not much I can do about 
that. Is this a bug that I should report with the devs?

thanks
Joris

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0ebae0c4-f6d1-4552-b71d-1afeb5c52e8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tests and temp tables

[Larry Martell]

On Thu, Feb 5, 2015 at 7:29 AM, Jani Tiainen  wrote:
> On Tue, 3 Feb 2015 19:38:31 -0500
> Larry Martell  wrote:
>
>> I have a django app that uses a temp table. In the real world this is
>> no issue, as each invocation of the app runs in its own MySQL session
>> so there cannot be any conflict with the temp tables. But in my tests
>> there are multiple requests sent, and apparently they are all in the
>> same session, as on the second request I get an error because the temp
>> table already exists. I tried logging out between requests, and I
>> tried creating a new Client instance for each request, but I still got
>> the error. Then I tried deleting the Client object, but I got Client
>> object has no attribute __del__.
>>
>> What I can do so that each request in a test has its own MySQL session?
>
>
> Instead of Django standard TestCase (which internally wraps all in single 
> transaction and makes transactions as a no-op), you should use 
> TransactionalTestCase.
>
> https://docs.djangoproject.com/en/1.7/topics/testing/tools/#transactiontestcase

Thanks for the reply Jani. We're using 1.5 and I don't think this is
available in that version. We'll probably be moving to 1.6 soon
though, and it is there. But I'm not sure how this will be useful to
me. The docs say "A TransactionTestCase resets the database after the
test runs by truncating all tables."  My test code is something like
this:

# load test data
# login
response = self.client.get('...')
self.assertEqual(response.status_code, 200)
# collect results

response = self.client.get('...')
self.assertEqual(response.status_code, 200)
# collect results

and so on. I need the temp table to get dropped between each get call.
The best way to do this is if each is in its own MySQL session. Having
the table truncated doesn't really accomplish this. I think I will
have to modify the code to drop the temp table after it's used. I hate
to muck with working production code to accommodate a test, but I also
don't want the test branch to have a different code base from the
production branch. I'll probably go with the former option.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY5wVz5nJffYQXGiczfSN_K8wRqDBbGp2sGW%3Dt%2BLQTQ7Ww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Login in all pages

[Juan Diego Gonzalez]

Hi, I need to put the django login feature in all pages, I mean, the user 
will be able to login in the reserved area of the web from any public page.

I have all the implementation done, and it works with a single page, in 
this way:
url(r'^home/$', magic.views.login, {'template_name':'magic/index.html'}),

I have put the code in a template, and it works only with home page, that 
is logical. Could anyone help me, please. I doesn't find any documentation.

May be something like url(r'^*/$', magic.views.login, 
{'template_name':'magic/index.html'}),

where * means any page.

Thank you very much.

Diego.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d44e8397-4b0a-4056-8f48-908793762ff4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django user (using django ORM) + SQLAlchemy for other db tables

[Mathieu Rodic]

I have been working on a Django project, where complex queries were 
required... so the Django ORM was out of question.

As I didn't want to have both Django and SQLAlchemy models hanging around, 
I chose to use aldjemy .

You can use this simple tutorial  to 
set it up on your Django app!

Le mardi 10 septembre 2013 18:34:48 UTC+2, Dennis a écrit :
>
> Any advice (or potential problems) with using SQLAlchemy with the django 
> framework but keeping the django user auth module?
>
> The django ORM would be used for the auth module (and its user table).
> SQLAlchemy ORM would be used for other tables and also to read (but not 
> write) the django user table.
>
> This combination would allow the power of SQLAlchemy but maintain 
> compatibility with django auth -- a sweet combination!
> Of course, the django admin system would likely not work, but that's ok.
>
> I thought this combination would work without being too much of a headache.
> But when I posted this on the SQLAlchemy google group for advice, the 
> response was negative: they do not recommend using this combination:
> https://groups.google.com/forum/#!topic/sqlalchemy/VlR2At_mUcE 
>
> But the django experts are on the django mailing list, so I thought I 
> would ask this group too.
> Just wondering if others have tried this combination and what issues might 
> have come up.
> From my google searching, the 2 references below (and their references) 
> are really the only mention of this approach on the web!
> So, it would be great to get some definitive advice on this seemly 
> reasonable approach.
>
> This approach is described in the stackoverflow comment here:
>
> http://stackoverflow.com/questions/18465197/how-do-i-start-with-django-orm-to-easily-switch-to-sqlalchemy#comment27166795_18476898
>
> The method to integrate SQLAlchemy into django is described here:
>
> http://stackoverflow.com/questions/6606725/best-way-to-integrate-sqlalchemy-into-a-django-project
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b0fbc0fd-2c4c-4d1d-b3cb-1be8849be023%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: subdomains and HOST in settings.py?

[Vijay Khemlani]

I'm not following, in the Django settings there is no "HOST" entry (other
than the one used to connect to the database)

https://docs.djangoproject.com/en/1.7/ref/settings/

If you're talking about "ALLOWED_HOSTS", then that one is only a whitelist
of allowed domains.

Try and describe your problem with more detail, What error are you getting?
What problem with JQuery are you having?

On Thu, Feb 5, 2015 at 9:48 AM, Abraham Varricatt <
abraham.varric...@googlemail.com> wrote:

> Ok, I think I goofed up asking the question here. I noticed that there was
> a HOST setting defined in the django documentation and assumed it was the
> same thing, but some more code investigation, reveals otherwise.
>
> But I *am* running into a tangential issue. I mentioned that if I set the
> value of HOST=alice.example.com that the site works for alice? Well, I
> did a bit of middleware tweaking so that the value of settings.HOST would
> get changed depending on the user, but that doesn't seem to have helped. :(
>
> -Abraham V.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/52349660-aaa1-44ac-9c5f-d3b8fa28a230%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALn3ei1_%2BsoofK2SCcJUXYF9ihDegFhgLjph1%3D--KDH7hbGFoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Strange error with reverse() when running tests

[João Sampaio]

There are 3 Python files attached.

I have my URL file attached. I'm using django-rest-framework (in case you 
are wondering what the routers are). When I use ./manage.py test with the 
first file (file1.py), the tests succeed. When I do the very same thing 
with the second file, the tests fail. The only thing changed between the 
files is the addition of this code:

def test_update_member_phone_number(self):
member = self.create_national_team_member()

url = reverse(r'nationalteam-member-phone-number',
  kwargs={r'pk': member.id})

The error is this one:

==
ERROR: test_update_member_picture (main.tests.test_national_team.
NationalTeamTestCase)
--
Traceback (most recent call last):
  File 
"/home/jpmelos/devel/ideation_admin/ideation_admin/main/tests/test_national_team.py"
, line 177, in test_update_member_picture
kwargs={r'pk': member.id})
  File 
"/home/jpmelos/devel/ideation_admin/venv/lib/python2.7/site-packages/django/core/urlresolvers.py"
, line 551, in reverse
return iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args, **
kwargs))
  File 
"/home/jpmelos/devel/ideation_admin/venv/lib/python2.7/site-packages/django/core/urlresolvers.py"
, line 468, in _reverse_with_prefix
(lookup_view_s, args, kwargs, len(patterns), patterns))

NoReverseMatch: Reverse for 'nationalteam-member-update-picture' with 
arguments '()' and keyword arguments '{'pk': 10}' not found. 1 pattern(s) 
tried: ['national-team/(?P\\d)/update_picture/$']

As you can see in the exception text, the pattern does seem to match. The 
error seems to happen in a test method that is not even related to the one 
added to the tests. What is going on? It doesn't make any sense to me. How 
come the mere addition of a call to reverse can cause the tests to crash?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/68cd8a2c-b3aa-4584-b11d-0d52e259dbf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# -*- coding: utf-8 -*-
import json

from django.core.urlresolvers import reverse
from main.models import PhoneNumber, TeamMember, Team
from main.tests.creator_test_case import CreatorTestCase
import os
from rest_framework import status


class NationalTeamTestCase(CreatorTestCase):
def test_retrieve(self):
self.create_national_team_member(picture=r'foto.jpg')
member = self.create_national_team_member()

phone = self.create_phone_number(member=member)

url = reverse(r'nationalteam-list')
response = self.client.get(url)

self.assertEqual(url, r'/national-team/')
for member in response.data[r'members']:
self.assertIsInstance(member.pop(r'id'), int)
self.assertEqual(response.data, {
r'members': [
{
r'name': u'Arnaldo',
r'email': r'arna...@gmail.com',
r'picture': r'http://testserver/media/foto.jpg',
r'phone': None,
},
{
r'name': u'Arnaldo',
r'email': r'arna...@gmail.com',
r'picture': None,
r'phone': phone.id,
},
]
})
self.assertEqual(response.status_code, status.HTTP_200_OK)

for member in TeamMember.objects.all():
member.delete()
for team in Team.objects.all():
team.delete()

def test_add_member(self):
url = reverse(r'nationalteam-list')
response = self.client.post(url, json.dumps({
r'name': u'Henrique',
r'email': r'henri...@gmail.com',
}), content_type=r'application/json')

self.assertEqual(url, r'/national-team/')
member_id = response.data.pop(r'id')
self.assertIsInstance(member_id, int)
self.assertEqual(response.data, {
r'name': u'Henrique',
r'email': r'henri...@gmail.com',
r'picture': None,
r'phone': None,
})
self.assertEqual(response.status_code, status.HTTP_201_CREATED)

TeamMember.objects.filter(id=member_id).delete()
for team in Team.objects.all():
team.delete()

def test_update_member(self):
member = self.create_national_team_member()

url = reverse(r'nationalteam-member', kwargs={r'pk': member.id})
response = self.client.put(url, json.dumps({

Re: subdomains and HOST in settings.py?

[Abraham Varricatt]

Ok, I think I goofed up asking the question here. I noticed that there was 
a HOST setting defined in the django documentation and assumed it was the 
same thing, but some more code investigation, reveals otherwise. 

But I *am* running into a tangential issue. I mentioned that if I set the 
value of HOST=alice.example.com that the site works for alice? Well, I did 
a bit of middleware tweaking so that the value of settings.HOST would get 
changed depending on the user, but that doesn't seem to have helped. :(

-Abraham V.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/52349660-aaa1-44ac-9c5f-d3b8fa28a230%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tests and temp tables

[Jani Tiainen]

On Tue, 3 Feb 2015 19:38:31 -0500
Larry Martell  wrote:

> I have a django app that uses a temp table. In the real world this is
> no issue, as each invocation of the app runs in its own MySQL session
> so there cannot be any conflict with the temp tables. But in my tests
> there are multiple requests sent, and apparently they are all in the
> same session, as on the second request I get an error because the temp
> table already exists. I tried logging out between requests, and I
> tried creating a new Client instance for each request, but I still got
> the error. Then I tried deleting the Client object, but I got Client
> object has no attribute __del__.
> 
> What I can do so that each request in a test has its own MySQL session?


Instead of Django standard TestCase (which internally wraps all in single 
transaction and makes transactions as a no-op), you should use 
TransactionalTestCase.

https://docs.djangoproject.com/en/1.7/topics/testing/tools/#transactiontestcase


-- 
Jani Tiainen

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20150205142945.6569122d%40jns42-l.w2k.keypro.fi.
For more options, visit https://groups.google.com/d/optout.

subdomains and HOST in settings.py?

[Abraham Varricatt]

Hello,

I'm trying to implement custom subdomains on a customer site and am having 
trouble understanding how the HOST option in settings.py works. The 
requirement is that if a user logs in, they should see their own username 
as the subdomain. So for example if we have 3 users - mark, alice and bob. 
Now, if mark is logged in, he should interact with http://mark.example.com 
. If alice is logged in, she should access http://alice.example.com and so 
on. 

I've implemented this via custom middleware. What the middleware does is; 
if whoever is accessing the site is a logged in user, check if they are 
accessing the site via their respective subdomain entry. If not, prepend 
their username to their request and issue a redirect to their web-browser. 
The idea here is that if a logged in user (mark) tried to access 
http://www.example.com/food/apple then he would be redirected to 
http://mark.example.com/food/apple

This works half-way. My users are able to login to the site, but for some 
cases, where I need to call 3rd party APIs (and some jquery), things aren't 
working as they should. It's kindof difficult to describe the issue, but 
what I discovered is that in my settings.py file, if I set 
HOST=mark.example.com , then the site works perfectly for user mark, but is 
partly broken for the others. If I set HOST=alice.example.com, things work 
perfectly for alice, but not anyone else. 

Does anyone have any good explanation for this behavior? Or should I be 
trying a different approach? We're running django 1.5.

Puzzled,
Abraham V.



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b0657dc4-d35c-4562-9f87-c276cfacf00c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.