Re: Dynamic View Selection

[Russell Keith-Magee]

Yes - but it doesn’t depend on some hidden feature of Django. It’s 

A Django View is just a function that accepts a request + args, and returns a 
response. That view can, itself, call other functions - including other 
functions that can act as views. So, you could write a “switch statement” view:

def switch_view(request, arg1, arg2):
if client_app_name == ‘xxx’:
return xxx.view(request, arg1, arg2)
else:
return base_view(request, arg1, arg2)

The logic of exactly how to manage the “switch” is entirely up to you.

Depending on how you set up your client sub-packages, you might even be able to 
use import logic to your advantage:

def switch_view(request, arg1, arg2):
try:
client_module = importlib.import_module(‘project.%s.emailer.view’ % 
client_name)
return client_module.view(request, arg1, arg2)
except ImportError:
return base_view(request, arg1, arg2)

Yours,
Russ Magee %-)

> On 11 Aug 2017, at 5:32 am, Khai Weng Au Yeong  wrote:
> 
> Not sure if this has been covered before, but I was thinking about this for 
> awhile.
> 
> Is there a way to dynamically select a View to be used by a URL without 
> having to replicate the URL dispatcher over and over via a "superceding" like 
> method. Like for example, in my project (let's say it's generic), if I have 
> "BaseEmailer" at ".emailer.views" and I have a client with a 
> special-case need installed at ".clients.emailer.views", can I 
> get Django to dynamically select it just based off this logic: if 
> client-app-name = base-app-name?
> 
> -- 
> 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/bc82a384-dec5-4f0a-8cb4-2e4c642b3677%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/F5301BC5-CD27-4EC9-A62E-9E32DFB1B22C%40keith-magee.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple User Types in Django 1.11

[Russell Keith-Magee]

Short version: You don’t.

Your site may have 2 types of user - but that doesn’t mean you have 2 user 
models. The user model is primarily for determining authentication; 
authorisation can be handled separately. 

So - set up a user model the way you normally would; then define a Teacher 
model and and Student model, each with a OneToOneKey to User. The user logs in, 
and you can determine what type of user they are by looking for the existence 
of a “teacher” or “student” attribute. You can then perform permission checks 
etc as appropriate by looking for user.student. or 
user.teacher..

As a side effect, this also allows for the edge case where a student is *also* 
a teacher - e.g., at a university, I might be studying business while teaching 
computer science.

Yours,
Russ Magee %-)

> On 24 Jul 2017, at 7:09 PM, stan  wrote:
> 
> What is the best way to create multiple user types in Django 1.11?
> 
> For example, an e-learning platform will need 2 user models: Students and 
> Teachers, which have different permissions and different attributes/methods
> 
> -- 
> 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/a5127741-73a1-4a34-8e4e-ab753c6aab7d%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/13239165-5A74-4409-ABEB-7A01D58E5E50%40keith-magee.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Virtual Environment

[Russell Keith-Magee]

Hi Yingi,

Once you create a virtual environment, it is an isolated sandbox. It doesn’t 
have access to the world outside that sandbox. That includes Django - your 
virtual environment will need to have Django installed separately, even if your 
“main” Python 3.5 install already has Django installed.

Yours,
Russ Magee %-)

On 12 Jun 2017, 9:10 PM +0800, yingi keme , wrote:
> Hello
>
> I have this issue i am trying to resolve. I installed django directly into my 
> Python35 directory without creating a new virtual environment for my project.
>
> However, now i want to create a new virtual environment for a new project. If 
> i make some modifications in django inside this new virtual environment, will 
> it not affect my previous project.? Do i need to install a new django 
> entirely?
>
> --
> 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/857441fd-c46f-48b1-818e-13380d4c0072%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/330dd057-0b22-4cad-83ba-25837e8f52a7%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: Session Variables

[Russell Keith-Magee]

Please stop spreading FUD like this. The Django Community Code of Conduct isn’t 
a blunt instrument attempting to stop all dissent or disagreement. It’s there 
to ensure that everyone treats everyone else with respect in all communications.

The fact that Daniel criticised Hungarian notation is in *no* way a violation 
of the CoC. It’s fine to have opinions about Hungarian notation (or any other 
technology or stylistic choice, for that matter). However, the dismissive and 
contemptuous tone he used to voice his disapproval *is* a likely violation of 
the CoC.

So - go right ahead and have opinions. Just choose your words when you voice 
them, and remember: we’re all humans; we can all have different opinions and 
preferences; and there may be situations and circumstances that affect those 
choices that aren’t always obvious on first inspection.

Yours,
Russ Magee %-)

On 31 May 2017, 4:08 AM +0800, ludovic coues , wrote:
> Pretty sure the django code of conduct is against criticizing the use
> of Hungarian notation.
>
> 2017-05-29 12:29 GMT+02:00 Daniel Roseman :
> > On Monday, 29 May 2017 06:04:02 UTC+1, James Schneider wrote:
> > >
> > >
> > > On May 28, 2017 9:35 AM,  wrote:
> > >
> > >
> > > tFetchData = users.objects.get(emailid = lEmailId)
> > >
> > > request.session['sPassword'] = tFetchData.userroles
> > > request.session['sCompanyId'] = tFetchData.companyid
> > >
> > > This code didn't appear to have anything to do with your question.
> >
> >
> > Also, Hungarian notation? Really?
> >
> >
> > --
> > 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/5427f3fe-4345-41b4-9a46-c0b037ece73b%40googlegroups.com.
> >
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
> Cordialement, Ludovic Coues
> +33 6 14 87 43 42
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/CAEuG%2BTZWJo3kX3AjFR_Lkf7JRkkVVjwrTMTQo9KkKZjmMoFZxQ%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/acb46478-8232-4154-ab65-b15563cecb12%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: vs {{ form }}

[Russell Keith-Magee]

On 16 May 2017, 12:51 AM -0700, guettli , 
wrote:
>
> I know that real super heroes prefer the hard way. I don't like the hard way. 
> Call me wuss, pussy, weenie if you want to.

That kind of language is completely unnecessary. I don’t care how frustrated 
you are - the Django community code of conduct requires that you keep a civil 
tone. If you persist in using language like this, we’ll block your account from 
posting.

Yours,
Russ Magee %-)

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

Re: Theming

[Russell Keith-Magee]

Hi Clinton,

On Sat, Apr 8, 2017 at 4:05 PM, Clinton Blackburn <
clinton.blackb...@gmail.com> wrote:

> Russ,
>
> How would this work for base/nested templates? Say my view is rendering
> the potential templates ['my-theme/page.html', 'page.html'], and the
> templates inherits base.html. Do I have to override base.html for every
> theme if I want base.html (or any other child/parent template) to be
> theme-able? Is there a version of {%include%} that takes an array, or will
> I need to write my own tag?
>

The template loading list (i.e., [‘my-theme/page.html’,
‘page.html’]) indicates which template will be rendered. Each of those
template can, themselves, include or extend any other template they want.
So, ‘my-theme/page.html’ could extend ‘page.html’, which could, in turn,
extend ‘base.html’ - or both templates could directly extend ‘base.html’.

The argument that is passed to {% extends %} is also something that can be
paramterized - so, for example, you can pass in a variable as template
context that contains the “parent” template - so you could do something
like having “page.html” that starts “{% extends theme %}”, and then pass in
{“theme”: “path/to/theme.html”} as context.

The same applies to {% include %} - anywhere that you pass in a string in a
template could, potentially, be a variable.

The approach that will work best depends on exactly what “theming” means in
your context.

Is it the same basic structure that just has a different style sheet? Then
having a template with {% include theme %} will probably be best.

Or is it a base structure where key bits of content are different? In that
case, having a my-theme/page.html that extends page.html, and using the
template loader trick will probably be best.

Or are the same *pieces* on each page, but laid out differently for each
user?  In that case, you probably want a page.html that starts with {%
extends theme %}, so that the theme establishes basic page structure, and
the page defines the blocks that are placed into that structure.

Yours,
Russ Magee %-)

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

Re: Theming

[Russell Keith-Magee]

On Sat, Apr 8, 2017 at 1:28 AM, Clinton Blackburn <
clinton.blackb...@gmail.com> wrote:

> Has anyone solved site-aware theming? I have a multi-tenant site (using
> sites framework) and I want to render custom templates for each site. My
> current design calls for a default design, and overrides of the base
> template (or child templates) for each site. Obviously, I can achieve the
> overrides by prepending the site/theme name when I include a
> template/static file. However, this does not allow for easy support of a
> default fall-back.
>

Actually - it does.

Any time you specify a template to render, you can also specify a *list* of
templates. So, you can do something like this:

def my_view(request):
…
return render(request, [
‘path/to/template/%s/template.html’ % user_theme,
‘path/to/template/default/template.html’,
], {…context…})

That will pick the user’s theme by default; if the user’s theme doesn’t
specify a given template, or the user doesn’t have a theme (or the user’s
theme is set to default), it will use the default theme directory.

Hope that helps!

Yours,
Russ Magee %-)


> How have others solved this problem? Are you using thread.local/global
> variables, as I've seen in some locations?
>
> Are there any plans to support a request/site-aware template loader?
>
> Thanks,
>
> Clinton
>
> --
> 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/8aaf04dc-2de7-4972-8ae5-aaaefa2bf17f%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/CAJxq84-T8hYB5NrC0PY9%3D_J6nw%2BY57cK-Zrt5Qj-Qz5C%3DQggag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What was the rationale behind ClassBasedView.as_view()

[Russell Keith-Magee]

There’s also a summary of the various options that were considered:

https://code.djangoproject.com/wiki/ClassBasedViews

Yours,
Russ Magee %-)

On Tue, Mar 14, 2017 at 10:08 AM, Frederik Creemers <
frederikcreem...@gmail.com> wrote:

> That makes heaps of sense, thanks!
>
> On Mon, Mar 13, 2017 at 10:49 PM Daniel Roseman 
> wrote:
>
>> On Monday, 13 March 2017 18:36:46 UTC, Frederik Creemers wrote:
>>
>> Django views are just functions that take a request, and possibly some
>> other args, and return a response. To get such a view from a class based
>> view, you can  `as_view()` on it. Why is that? Wouldn't it make the code
>> neater to just implement `__call__` on the views? What was the reing behind
>> having `as_view`?
>>
>>
>> A search in django-developers would probably reveal the extremely
>> long-running thread that led to that specific implementation.
>>
>> But, briefly, allowing the CBVs to be instantiated in the URLs would
>> render them non-thread safe. Any attribute set on the object would persist
>> across all future requests, leading to information leakage and other very
>> bad behaviour. The `as_view()` construct is a (mostly successful) effort to
>> make it almost impossible to break the thread safety of the view objects.
>> --
>> DR.
>>
>> --
>> 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/ih8_zwLQVgc/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 https://groups.google.com/group/django-users.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-users/1b6323e5-ca93-4ccf-91d5-da7d5a72f6b7%
>> 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/CAJA%3DsDTY_m3PkYPeL5pW-gyB%2BcC__
> HJvRf1_iEPBD1nBd3%2BuAg%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/CAJxq84-wjL2Vdd5dEGtgxhB%2BwvG0Maarr%3DjuM9qC58MZEdY87g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is there a spanish version of Two Scoops of Django?

[Russell Keith-Magee]

Hi David,

On Wed, May 18, 2016 at 6:40 AM, David Alejandro Reyes Milian <
davidreyesmilia...@gmail.com> wrote:

> Thanks for asking. I could like to make a full Spanish translation  of
> this amazing book, how can I speak to Audrey or Danny? Can you help?
>

Danny is @pydanny on twitter; Audrey is @audreyr. The contact email for Two
Scoops is he...@twoscoopspress.org.

Russ %-)

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

Re: Is there a spanish version of Two Scoops of Django?

[Russell Keith-Magee]

Hi David,

To the best of my knowledge, there aren’t any translations of Two Scoops
available - but I’ve asked Audrey and Danny to confirm. If there is, I’ll
report back and let you know.

Yours,
Russ Magee %-)

On Tue, May 17, 2016 at 9:03 PM, David Alejandro Reyes Milian <
davidreyesmilia...@gmail.com> wrote:

> Do you know if there is a Spanish version of Two Scoops of Django?
>
> --
> 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/9548ab5d-d529-4eda-a84b-37c14780fd68%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/CAJxq84_sA_RyX-epTw9xYZsvtVM2jSn8vErEygcY2Cb1714VZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DjangoCon US 2016

[Russell Keith-Magee]

The complimentary ticket for speakers is new for DjangoCon US this year -
it’s the first year that *all* speakers have been guaranteed a free ticket.
Complimentary speaker tickets have existed for DjangoCon Europe and AU in
some years, and DjangoCon US has given free tickets to speakers as a
priority of the financial aid program.

The reason we’ve seen the change this year isn’t because of any problems
getting speakers - it’s purely a philosophical change. As I understand it,
the new organizing group (DEFNA) felt that asking speakers to pay was
preventing some people from even proposing a talk, simply because if they
were accepted, they wouldn’t be able to afford a ticket. It’s also a tacit
recognition of the effort that goes into preparing a good conference
presentation.

Yours,
Russ Magee %-)

On Thu, Mar 24, 2016 at 11:46 AM, Alex Heyden  wrote:

> The financial aid is nothing new, but "everyone pays" traditionally meant
> that everyone, from speakers to organizers to volunteers, paid for a
> ticket. Free tickets for speakers is unusual outside of paid keynote
> speakers.
>
> On Wed, Mar 23, 2016 at 6:29 PM, James Bennett 
> wrote:
>
>> From reading the CfP page I don't see much of a change; as far as I know
>> with DjangoCon (and PyCon) it's always been the case that, as long as there
>> was a financial aid program, speakers could make use of it, and I believe
>> one or the other or both have prioritized speakers to ensure that getting
>> to the conference isn't a hardship for them. It might not always have been
>> presented in exactly those terms (or that clearly), though, so perhaps the
>> change is being so up-front about it :)
>>
>> On Wed, Mar 23, 2016 at 2:20 PM, Alex Heyden 
>> wrote:
>>
>>> This is an unexpected break from the old "everyone pays" policy. Has
>>> there been trouble getting proposals in the past?
>>>
>>> On Wed, Mar 23, 2016 at 10:00 AM, Andrew Pinkham 
>>> wrote:
>>>
 We are pleased to announce that DjangoCon US will be hosted by the
 Wharton School at the University of Pennsylvania in Philadelphia from July
 17-22!

 The call for proposals is open!
  We
 want to hear about your experience with and around Django. However, talks:

 - Don't need to be about Django specifically
 - Don't need to be 100% fleshed out.
 - Don't need to be about software directly
 - Don't need to be advanced

 Apply now! The deadline is April 18th.
 

 Never spoken before? Not a problem! There are speaker mentors that will
 help you (see the link above).

 Is cost a concern? Not a problem! Apply for financial aid (deadline
 April 25th). 

 You can follow all the latest on Twitter
 .

 Hope to see you in Philly!

 Andrew

 --
 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/AE8F82AA-269C-473E-863D-6E6EAF242219%40andrewsforge.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/CA%2Bv0ZYU-7%2B4EYAdQnk3qCYdC4DXBS%2B3yu9z9frJkAWBaGKQkDg%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/dj

Re: Looking for Django people to attend/staff booth at PgConf.US 2016

[Russell Keith-Magee]

Hi Joshua,

On Tue, Mar 15, 2016 at 2:23 AM, Joshua D. Drake 
wrote:

> Hello,
>
> We at PgConf.US (a 501c3 PostgreSQL conference) are looking for a
> community team to staff a community booth at PgConf.US 2016!. Here are the
> details:
>
> PgConf.US is held in NYC and the 2016 version is happening April 18-20th
> at the Brooklyn Bridge Marriott and we are expecting at least 500
> PostgreSQL community members. In the interest of Open Source collaboration
> we would like to invite ~ 12 community projects to attend and have a table
> in our exhibition hall. Further, the party on the 19th is open to all, door
> fee of 20.00 for non conference attendees. We are hoping to drive it up to
> a 1000 person social!
>
> The details are as follows:
>
> * Exhibit on 04/19 - 04/20
> * 5 foot table (free) in community pavilion
> * 10% discount code for conference to help you promote your community
> attendance.
> * 5 free full admission passes (including party, not including training)
>
> Party link: http://www.meetup.com/postgresql-3/events/229101241/
> Conference link: http://www.pgconf.us/
>
> Is this something your community would be interested in?
>

Quite possibly - but the django-users mailing list isn’t the best place to
ask; this is the general purpose mailing list for “how do I” type
questions. If you haven’t already, I’d suggest contacting the Django
Software Foundation directly (foundat...@djangoproject.com) - they’ll be in
a better position to rally the community behind something like this.

Yours,
Russ Magee %-)

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

Re: Python Windows + Web +Mobile application: Kivy or Django

[Russell Keith-Magee]

On Fri, Feb 5, 2016 at 10:42 PM, MHK  wrote:

> Hi All,
>
> I am planning to develop an application which should be mainly work with
> desktop and latter may be use the same desktop app to convert into web and
> mobile application using python. I wanted to know whether kivy will suffice
> for all the three platforms (desktop, web and mobile) or do I need to work
> on kivy for desktop and Django for web. Please suggest
>

It depends on what you want to produce.

Django by itself is a server-side tool. You’re not going to be able to
write a mobile application in the “available in the app store” sense of the
word. However, you will be able to write a web page that is adaptive to
mobile devices; you can also use HTML5 features like manifests to produce
an app-like experience on mobile. The same goes for desktop apps - you can
write something that will load in a browser, but unless you’re going to
wrap that web page up in a single-page app loader (like Fluidapp [1]),
you’re going to need different tools to write the desktop app.

Kivy, on the other hand, can only be used to make standalone apps. To the
best of my knowledge, there isn’t a “browser” option for Kivy - you’d be
writing a Kivy app for the mobile app (and possibly a desktop app as well),
with Django providing the server side (if a server-side is even needed -
your requirements aren’t clear). However, Kivy apps aren’t really “native”
- They *run* as native apps, but the widgets they expose are all
custom-drawn Kivy widgets. Ivy takes the approach of having a common widget
set across all platforms, rather than providing native widgets on each
platform.

I’d also be remiss if I didn’t point you in the direction of BeeWare [2]
 it’s a project that I’m working on to improve the story for developing
Python applications for mobile. It’s still early days - definitely not as
mature as Kivy - but if you’re willing to put up with plenty of sharp
edges, and contribute to an early stage project, you can develop completely
native mobile (and desktop) applications in Python.

[1] http://fluidapp.com
[2] http://pybee.org

Yours,
Russ Magee %-)

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

Re: Scaling Django

[Russell Keith-Magee]

On Wed, Feb 3, 2016 at 11:30 PM, Joshua Pokotilow 
wrote:

> At the startup where I work, we've written a lot of our server code in
> Django. So far, we've adopted a "build it fast" mentality, so we invested
> very little time in optimizing our code. A small amount of load testing has
> revealed our codebase / infrastructure as it stands today needs to run
> faster and support more users.
>
> We recently hired some new engineers who are extremely skeptical that we
> should optimize our existing code. Their main concerns are:
>
> - We need to move to a service-oriented infrastructure because Django is
> too monolithic (monolithic = technology lock-in & difficult to troubleshoot)
> - It's too easy to write slow queries using the Django ORM
> - It's hard to hire Django engineers
> - While Instagram and DISQUS use Django to service large numbers of
> people, they don't use it for any serious backend work
>
> After having worked with Django for the last 3 years, I'm a big believer
> in it, and I believe it would scale. To defend my position, I've pointed
> out to my colleagues that it's easy to identify bottlenecks with tools like
> the Django Debug Toolbar and Yet Another Django Profiler. With my
> colleagues present, I've isolated and fixed significant speed problems
> inside of a few hours. I don't believe the Django ORM is inherently bad,
> although I do think that coders who use it should Know What They're Doing.
> Finally, I've referenced blog entries that talk about how Instagram and
> Disqus use Django on the backend for backend-y tasks.
>
> Despite my best efforts, my colleagues are still pushing to have us
> rewrite large portions of our infrastructure as separate services before we
> try to fix them. For example, we have one slow REST endpoint that returns a
> boatload of user data, and so there's talk about using a new microservice
> for users in lieu of our existing Django models. Even if we are able to fix
> bottlenecks we encounter in a timely fashion, my colleagues fear that
> Django won't scale with the business.
>

My immediate reaction, knowing nothing about the site or it’s codebase -

1) There’s nothing they’re proposing that excludes Django from the mix.
2) From an engineering management perspective, the solution they’re
proposing is much more concerning than the problems you’re describing.

My suggestion for convincing management:

Tell them that you can write Microservices in Django. Because you can.
Build a minimal Django stack - something that just returns a static Hello
World - and do some load testing. This will prove that Django can serve
high load - or at least as much load as whatever technology they’re
proposing.

Tell them that Microservices is just a new word for something software
engineers have been calling “High cohesion, low coupling” since the 1960s.
The only difference is that this time, instead of using the low latency,
high speed interface of a function call, we’re using the slow, unreliable
transfer of HTTP. If you’re actually focussing on performance, it’s trivial
to build a high cohesion, low coupling stack in *any* technology. All that
Webservices do is enforce this by making the inter-module barrier obvious.

Tell them that Microservices aren’t magic fairy sauce for speed. If the
issue with your existing codebase is the speed of database queries, that
problem isn’t going to go away by putting your code behind microservices.
You’re just going to add the cost of inter-service HTTP transfer to the
overhead of making a query. And if you’re putting something essential -
like the user database - behind a service, then you’d better be prepared to
add the round-trip time of a HTTP lookup onto Every. Single. Page. (Tell me
again how this is good for performance?)

Teach them about Second Systems Syndrome [1] [2].

[1]
https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_second-system_effect
[2] http://coliveira.net/software/what-is-second-system-syndrome/

Tell them that while Django engineers might be hard to hire, they’re also
relatively easy to grow from scratch. DjangoGirls proves you can take
people with no experience in programming and make them competent Django
developers. Take someone with a history in *any* programming language, and
you can teach them Django; hire one or two Django experts to provide an
internal knowledge and review, and you’re set.

Lastly, tell them that despite their protestations, your site isn’t
Instagram, Disqus, or anything like it. 99% of web sites are not in the top
1% of websites by traffic. Your website is *not* in the top 1%. It might be
one day. But it isn’t now. And if you’re *ever* in a position where you
might end up in the top 1% - I can *guarantee* that it will be accompanied
by a metric buttload of engineers and money who will have a lot more
experience in scaling large scale services than any of the people who are
proposing microservices as a silver bullet.

Now - I’m saying all this without having actually seen your code or

Re: async / await

[Russell Keith-Magee]

On Thu, Jan 21, 2016 at 8:19 AM, Benjamin Melki  wrote:

>
>
>
> To implement this sort of feature, you need to have a worker queue -
> Celery is the heavy duty answer for this; if you just need a cheap and
> cheerful answer, RQ is a fairly easy-to-use option, or you can
> roll-your-own in the database without too much trouble.
>
>
> Thank you Russel, for the informative answer. It’s all pretty clear, and
> it is a great news to learn that some async patch will make it into Django.
>
> Just to be perfectly clear…. you talk about celery and indeed i’ve seen
> some tutorials about it.
> But most were written before 3.5 python.
>
> Specifically for the image processing, do I need to install celery, can’t
> I just use async / await for this task ?
>

The Python 3.5 async/await keywords are an entirely different beast, for an
entirely different problem - that’s why I flagged the fact that
“asynchronous” was a misleading word to use in this case.

I’m sure you *could* use async/await to implement an image processing
solution, but you wouldn’t gain much. A user would still connect to your
server, start a request, which would spawn (or acquire) a thread to do
image handling… and then wait until the background processing was complete
before “await”ing, and then returning the result to the user. The end user
experience is still going to be “nothing is seen until the entire process
is completed”, and absent of some very sophisticated server gymnastics, the
server thread is still going to be locked up waiting for the image
processing to return. All you will have achieved is a lot of complexity in
your code so that your image processing is handled in a separate thread.
You could do exactly the same thing without async/await by spawning a
subprocess or thread, and waiting/joining on the subprocess/thread response.

Ultimately, this is really all async/await is - syntactic sugar around
diverting program flow to an alternate thread (Insert suitable amounts of
hand waving here glossing over the details and nitpicking :-). You’re still
going to have a web server waiting for something, and a user waiting for a
finished request.

Moving to an all singing, all dancing asynchronous web server (such as
twisted, tornado, or a patched version of Django such as the Django
Channels that should be coming in an upcoming release), would solve the
server resource starvation problem, which I suppose is a good thing, but
the end user will still be waiting to see responses displayed - and
remember, it only takes 0.3s of lag for a user to declare that a user
interface is slow.

Remember, “asynchronous” isn’t magic fairy dust that makes everything
faster. You need to understand *what* is causing blocking in your algorithm
in order to evaluate if synchronicity is the problem you have. In the case
of image processing, you don’t want asynchronicity - you want background
processing.

Yours,
Russ Magee %-)

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

Re: async / await

[Russell Keith-Magee]

Hi Benj,

On Thu, Jan 21, 2016 at 6:41 AM, Benj  wrote:

> Hi,
>
> on my django project, at a point i resize an image with pilow before
> associating it to django field, then saving the instance.
>
> is there any benefit in making the image resize / saving on disk async ?
>

Yes - although async isn’t the way I’d describe it - I’d describe this as
background task processing.

When a user hits your web server, the server generates a page, and returns
the content to the user. The user’s browser then displays the page. The
user doesn’t see *any* content until the entire page has been generated and
sent back to them. This means that it is critical that the page can be
computed quickly - if it isn’t, the user will observe this as a slow page
load.

So - if you’ve got a time intensive task, like resizing an image, you’re
generally advised to do that *outside* the request/response loop. You *can*
do it inline (or synchronously), and if you’re dealing with a low traffic
site with users that don’t mind an occasional delay, you might do it inline
just to expedite the development process. But if you’re on a high traffic
site, or if users will notice a delay, you should get any time-expensive
processing out of the page generation process.

There’s another reason to get time-expensive processes out of the page
generation process: server load. Web servers generally have a fixed
capacity - they can only be processing N requests at a time. Some web
servers can *accept* very large numbers of simultaneous connections (nGinX,
for example, can handle thousands) - but that’s only *accepting* the
connection - web servers will generally *process* a handful of requests at
a time (often some small multiple of the number of processors).

So - if you have something that takes a non-trivial amount of time to
perform, you will be locking up that web server thread until the processing
is completed. That means you’ve just reduced the number of available web
server threads. That means *everybody else* visiting your website will have
degraded performance, not just the person whose request caused the time
expensive task. If you’ve got a lot of users who simultaneously request the
same time-expensive view, *nobody* will be able to get a request processed,
because the web server will be tied up doing the time-expensive tasks.

The usual approach for this sort of problem (and image processing is the
classic use case) is a worker thread. The user submits their image, the web
server receives it, puts the image onto a work queue, and immediately
response with a success acknowledging receipt. In a completely separate
worker thread, images are taken off the queue, processed, and stored. This
means the user gets a fast response, doesn’t drag everyone else down with
them, but the work is still done.

This obviously imposes some extra overhead on your code - in your example,
you can’t assume the image exists, so you have to put in fallback
mechanisms when the user requests a page where the image needs to be
displayed.

To implement this sort of feature, you need to have a worker queue - Celery
is the heavy duty answer for this; if you just need a cheap and cheerful
answer, RQ is a fairly easy-to-use option, or you can roll-your-own in the
database without too much trouble.

As an aside - when web developers talk about “asynchronous” behaviour, they
are generally referring to things like chat clients. This is a situation
where the server is able to send data back to the client at will. “Classic
web” is client-driven; user requests a page, server provides it.
“Asynchronous web” is a different mode of operation, where the user
requests a specific thing which isn’t available yet; server provides it
when it is available. This approach *could* be used for something like
image processing, but it isn’t something Django is well set-up to manage at
present.


> I heard that since django is a non async framework, there is no interest
> in doing so. But is there ?
>
> I’m not sure exactly what you’ve heard - but it sounds like whoever told
you was misinformed.

Django doesn’t *currently* have any built-in asynchronous tools, but that
doesn’t mean we don’t want to add them, or that there aren’t options for
doing asynchronous work right now. There are a couple of patches, in
various stages of development, including one that just received a large
grant from Mozilla, that will add various flavours of asynchronous handling
to Django.

Yours,
Russ Magee %-)

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

Re: settings.py variables in fixtures

[Russell Keith-Magee]

Hi Salvatore,

On Mon, Dec 28, 2015 at 12:09 AM, Salvatore Scaramuzzino <
salvatorescaramuzz...@gmail.com> wrote:

> hi to everyone
>
> i'm newbye in django, but i really appreciate this useful framework. I
> have a simple question but i don't know if is appropriate.
>
> i have a fixture written in JSON and i use it to provide initial data to
> my webapp. i want to provide in this fixture absolute paths in order to
> store some images. is there a way to use in JSON fixtures (or in
> another format) variables defined in settings.py (eg. base path of the app)?
>

To make sure I’ve understood your use case: you want to have a JSON (or
similar format) file that contains absolute paths to some images, and load
these images into your database, relative to some setting in your
settings.py file.

If that’s the case, you probably won’t be able to use Django’s default
serializer framework - Django’s serialisers are designed to be little more
than a dump (and restore) of literal database content. Transforming input
along the way isn’t something they are designed to do. You *might* be able
to do something by writing a custom field and manipulating the
deserialisation code on the field, but honestly, it’s going to be more
trouble than it’s worth.

What you are trying to do is still completely achievable, though - you just
have to write your own management command. That command will take the name
of the JSON file as an argument, parse it and iterate through the content,
and process the absolute paths into whatever local storage path you want to
use.

I hope that makes sense; if it doesn’t (or I’ve misunderstood your use
case) let me know and I’ll elaborate some more.

Yours,
Russ Magee %-)

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

Re: What will be the replacement for .extra()?

[Russell Keith-Magee]

Hi Luis,

On Thu, Dec 10, 2015 at 7:10 AM, Luis Masuelli 
wrote:

> When I see the docs (
> https://docs.djangoproject.com/en/1.8/ref/models/querysets/#extra), I
> notice .extra will be deprecated and removed. Is there a plan for the
> replacement? As I see it, limiting ourselves to using Manager.raw() is not
> a good idea, since you cannot work anymore on a RawQueryset object (as you
> can work on any Queryset object you called .extra). So my question is: Is
> there a good replacement for .extra being planned?
>

Yes - the Query Expression API.

https://docs.djangoproject.com/en/1.9/ref/models/expressions/

Yours,
Russ Magee %-)

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

Re: Is django-nonrel still updating, or will be part of future django

[Russell Keith-Magee]

Hi Alex,

On Thu, Nov 19, 2015 at 5:09 PM, Alex Yang  wrote:

> Is django-nonrel still updating, or will be part of future django
>

I can’t comment on whether nonrel is still updating, but I can say with a
high degree of certainty that it is unlikely to be part of Django at any
point in the near future. Django has recently gained some new features (in
particular, a formalised Meta model) which should remove the need for an
invasive patch like nonrel; deep support for MongoDB (and other data
stores) should now be possible using public APIs. If you want more details,
see my talk at DjangoCon US this year:

https://www.youtube.com/watch?v=VgM0qmpHDiE

Yours,
Russ Magee %-)

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

Re: Merging Codeigniter withe Django

[Russell Keith-Magee]

Hi Masum,

On Sat, Nov 7, 2015 at 4:25 PM, Masum Hasan  wrote:

> Hi,
>
> I have a class project partially done with Django, but my lab partner has
> done her part in Codeigniter. I was wondering if it is possible to merge
> these two and complete the project?
> Any thought would help. Thank you in advance
>

It depends :-)

You’re not going to get a completely seamless merge - you’re not going to
be able to “import” your Django code into her Codeigniter project, or vice
versa.

However, you might be able to deploy a site that is “split down the middle”
by doing a bit of fancy web server configuration. For example, you could
configure your Django application to serve the homepage, and all URLs under
/foo; and configure the CodeIgniter project to serve all the urls under
/bar, but run them both in the same Apache instance. If you have similar
looking templates, the end-user won’t notice when they move from one
implementation to the other.

Two big areas of friction will be:

1) When someone logs in, you’ll need to make sure that they’re logged in to
both systems, and whatever login credentials you use can be shared. I don’t
know anything about CodeIgniter, but Django’s authentication backends are
fairly configurable, so you should be able to accommodate this.

2) If there is any shared data between the two projects, you’ll probably
need to make both projects talk to the same database. Django provides tools
like inspectdb and managed=False to help deal with legacy or external
database sources,

There will probably be other areas of friction too, depending on the nature
of your projects.

As an aside, with my
used-to-be-a-university-lecturer-and-is-now-a-grumpy-old-man hat on… :-)
One of the reasons you are assigned group projects is to teach you how to
collaborate. 2 people picking different web frameworks, and then trying to
smash them together at the end… that suggests to me that you’ve just missed
the point of the project. This is the sort of problem that should be
resolved at the start of the project, not patched over at the end.

Yours,
Russ Magee %-)

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

Re: Login with email address

[Russell Keith-Magee]

On Wed, Nov 4, 2015 at 11:58 PM, victor menezes 
wrote:

> I agree that it is time for django to change it (at least making the
> changes easier)
>

I’m intrigued - exactly how much easier do you want us to make it?

At this point, it is *literally* installing a third party app, adding that
app to INSTALLED_APPS , and adding an AUTH_USER_MODEL setting to your
configuration file.

Changing the default isn’t a viable option, because changing the default
user would break *every* Django project that assumes the current default
User model is the one in existence - which is to say, every Django project
generated to date that hasn’t deployed a custom User model.

We’ve also had an open ticket #20824:

https://code.djangoproject.com/ticket/20824

This would add an EmailUser as part of Django’s core. However, there are
some techncial issues associated with this:

https://groups.google.com/d/msg/django-developers/7feYlp9HqKs/Z_vv8O43vEUJ

We haven’t worked out how to resolve these issues; if there are any
suggestions, the idea has broad support from the core team.

Yours
Russ Magee %-)

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

Re: Authenticate users with both username and email

[Russell Keith-Magee]

Yes, there *is* a very simple way to implement “Email address as username”
-  you use a custom user model that implements that approach.

https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#substituting-a-custom-user-model

Django’s docs contain details of how to do this, and there are a number of
third party projects that have a ready-to-use implementation of “email
address as username” specifically.

Yours,
Russ Magee %-)

On Wed, Nov 4, 2015 at 11:50 AM, Patrick Breitenbach  wrote:

> Are you suggesting that there's a relatively easy way to implement "email
> address as username"? Is it as easy as just putting an email address into
> the username field? And making sure to update it when someone updates their
> email address?
>
>
> On Monday, January 19, 2015 at 2:33:35 AM UTC-8, James Schneider wrote:
>>
>> I guess I'm not clear on what you are trying to achieve. There are a
>> couple of scenarios to consider.
>>
>> As it stands with the default contrib.auth authentication backend,
>> sending both the username and email address entered by the user will only
>> work IF the user registered/was created using their email address as their
>> username, meaning that user.username is either their username (a string
>> that isn't their email), or an email address, regardless of what user.email
>> returns. The default contrib.auth authentication backend only looks at
>> user.username.
>>
>> What I suspect you want is to be able to use either user.username OR
>> user.email as the identifying tokens for the user in order to authenticate
>> them. For that, you'll need to roll at least a partial custom
>> authentication backend, in addition to the changes for the forms, etc. that
>> you've already laid out.
>>
>> From
>> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#writing-an-authentication-backend
>> :
>>
>> "If you wish to provide custom behavior for only part of the backend API,
>> you can take advantage of Python inheritance and subclass *ModelBackend*
>> instead of implementing the complete API in a custom backend."
>>
>> Specifically, you'll need to override the authenticate() method of the
>> authentication backend.
>>
>> I've done this, it's actually pretty easy. See:
>>
>>
>> https://github.com/django/django/blob/master/django/contrib/auth/backends.py#L11
>>
>> In this case, you should also roll a custom user model as well to ensure
>> that both user.username and user.email are unique columns. If you use the
>> email address as an identifying token, it will need to be unique among all
>> users, which is not true/enforced for the built-in contrib.auth User model.
>> You will also need to override the custom User manager for your new
>> CustomUser, probably with and override for get_by_natural_key(token) so
>> that the user can be retrieved in the backend authenticate() method. The
>> key change in get_by_natural_key() being the filter for the user object
>> being changed to something like User.objects.get(Q(username=token) |
>> Q(email=token)).
>>
>> (If you haven't seen the Q() notation, check
>> https://docs.djangoproject.com/en/1.7/ref/models/queries/#q-objects)
>>
>> The custom user you probably want is somewhat similar to the example
>> given in the docs:
>>
>>
>> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#a-full-example
>>
>> You'll need to add a 'username' field back in (remember to make it
>> unique) along with several other tweaks to be able to use either a username
>> or email field. An alternative would be a custom user class inheriting from
>> AbstractBaseUser and copying in the goodies you need from AbstractUser
>> (which is probably everything except the username and email fields, which
>> you'll be defining as unique). Be sure to include the Permission mixins
>> that AbstractUser has if you intend to use the built-in permission system
>> with your CustomUser.
>>
>> Sorry about the lengthy message, there are a bunch of ways to tackle
>> this, but ultimately I think you'll be rolling your own user and at least
>> part of the authentication system, not to mention having to customize the
>> user forms. The user will be slightly tricky, as there is no clear
>> inheritance path that will make it easy AFAICT, but the auth backend should
>> be just a class with a single authenticate() function if you inherit from
>> ModelBackend. Be sure to either include your custom backend in
>> AUTHENTICATION_BACKENDS, or possibly even replacing it if you go with the
>> Q() query I specified earlier (since an auth request using an email would
>> generate two authentication queries if both backends are used, and the
>> username field is checked twice).
>>
>> TL;DR; Overriding the user forms is probably not enough, you'll need a
>> custom user and custom authentication backend.
>>
>> Not sure if I made the situation better or worse, but HTH...
>>
>> Obviously, YMMV, I haven't tried this myself, but I have done a fair bit
>> of overriding for a custom object-based permis

Re: Password protect content

[Russell Keith-Magee]

Hi Andrew,

On Tue, Nov 3, 2015 at 12:37 AM, Andrew S  wrote:

> Hello,
>
> I have a folder full of HTML files that will reside on a subdomain.
>
> I would like to password protect these with user accounts etc.
>
>
> Can this be easily completed with Django? is there any packages that
> already do this?
>

Yes, and Yes.

The magic keyword you’re missing is X-SENDFILE - it’s a HTTP header that
lets Django manage authentication, but your static file server handle
delivering the actual content.

Here’s a blog post to show you how to set it up.

http://www.paulpepper.com/blog/2014/02/django-x-sendfile-and-apache/

Yours,
Russ Magee %-)

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

Re: Are jobs postings allowed on this forum?

[Russell Keith-Magee]

Hi John,

As long as they're on topic (i.e, for Django jobs), you're clear about
the geographical constraints on the job (e.g., only looking for people
in city X, relocation budget available; telecommuting welcome; US
citizen required), the job advertisement doesn't trigger any Community
Code of Conduct issues, and you don't start spamming the list as a
recruiter, you're free to post job advertisements.

Yours,
Russ Magee %-)

On Wed, Oct 7, 2015 at 3:23 AM, John Shields  wrote:
> Hi, does this forum allow job postings?
>
> --
> 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/30de2b49-9868-4030-b52b-c6b767056559%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/CAJxq84_w5R%2BQe5G9%2BvrjQqt5TTURW7xG5Z9E02tRnwN6KsTyNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Djangocon Costa Rica next year.

[Russell Keith-Magee]

On Wed, Aug 19, 2015 at 9:50 AM, Luis Zárate  wrote:

> Hello everyone,
>
> I want to organize the first "djangocon Costa Rica" next year, I know it's
> too soon to speak about this but it's the first time here and it's very
> important to do it well, so the community and I are planning to start the
> coordination of the event, we are looking for place and sponsors and of
> course your advice.
>
> We know that in this list are people that coordinate the event in his
> country and probably you have suggestions for us.
> We are looking for promotional material too and something like that, we
> follow the principe of DRY so if you have material that we can modify to
> adapt our purpose, please contact me privately.
>
> Thank you and any advice are welcome.
>

Hi Luiz,

Great to hear that there's a vibrant community in Costa Rica, and enough
enthusiasm to take on the task of organising a conference! I wish you the
best of luck!

One word of caution, though - the name "DjangoCon Costa Rica" is off
limits. Under the terms of the Django Trademark license [1], the name
DjangoCon is reserved for use by the Django Software Foundation. You're
free to choose another name with "Django" in it (within some boundaries) -
but even then there are some conditions you need to be aware of.

If you're coming to DjangoCon US in a couple of weeks, make yourself known
to me and I'll introduce you to the team organising that event - I'm sure
they'll have plenty of advice, and maybe even some resources to share.

If you've got any questions about the naming, or if there's anything the
DSF can do to help, let me know.

[1] https://www.djangoproject.com/trademarks/

Yours,
Russ Magee %-)
DSF President

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

Re: User and Permission from admin to the app

[Russell Keith-Magee]

Hi Predator,

Permission checks need to be manually added to each view, on a case-by-case
basis. Django can't "interpret" what your view is trying to do - all user
views look the same to Django - so you need to provide the extra
information to describe which permissions are needed at any given part in a
view.

For example, you might require "View" permissions to GET a particular view,
but require a Change permission (or multiple change permissions, if you're
modifying multiple objects, or even a custom permission) to POST to the
same view.

The easiest way to do this is to put the @permission_required decorator on
a view:

https://docs.djangoproject.com/en/1.8/topics/auth/default/#the-permission-required-decorator

However, you can also use user.has_perm('foo.add_bar') method inside a view
(returning a 404 or 403 if the test fails) if you need a more fine-grained
approach.

Yours,
Russ Magee %-)

On Thu, Aug 13, 2015 at 10:24 AM, Predator  wrote:

> Hi there!
>
> I have a question regarding user permissions.
>
> How can I use the user permissions that I have set in the admin to my
> django app?
>
> For example, I have a user* 'Trainee'* and in django admin, I set
> *'Trainee'* to only add to my model. So, 'Trainee' can only add to this
> model, not change and delete it. When I logged in to* my app*, I can
> still delete and change. I may be missing some vital points and I hope
> someone can point me to the right direction.
>
> Thanks and have a great day!
>
> --
> 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/d64cc98d-40c7-43b1-aecc-25fc7a1d752c%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/CAJxq8495Ds_gQ%3DOkraOuE%3D5LrVBjE%2B%3D1um32HBxAHLPtBS6FXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: is there anybody who test this django mongodb engine ?

[Russell Keith-Magee]

On Tue, Aug 18, 2015 at 3:31 AM, MahdiX  wrote:

> Hi folks
> I just start learning and using mongoDB , it's looks like a really nice
> replacement for mysql.
>

If you're judging relational databases by comparing to MySQL, you're really
not doing a fair comparison. MySQL is a *really* bad database. Before you
write off relational databases, you might want to do some research into
PostgreSQL.

Also, before you commit to MongoDB, might I suggest you look into the many
people with horror stories and cautionary tales about MongoDB:

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
http://www.quora.com/How-much-credibility-does-the-post-Dont-use-MongoDB-have
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/

... and the people who have demonstrated that PostgreSQL is faster than
MongoDB *at the types of problems that MongoDB is supposed to solve*.

http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality


> I was searching for 3rd party for using Mongo with django and I ends up
> with django-mongodb-engine.
> Has anybody test it?
> I'm looking for personal experiences
>

I haven't used it myself, but from what I'm aware of, if you *must* use
MongoDB, it's the best Django option out there at present.

Yours,
Russ Magee %-)

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

Re: pyjs - a compiler from Python to JavaScript

[Russell Keith-Magee]

On Sat, Aug 8, 2015 at 4:27 PM, Uri Even-Chen  wrote:

> Hi Russ,
>
> I checked the projects you mentioned, but is it possible to communicate
> with other JavaScript scripts such as jQuery, jQuery UI and plugins for
> jQuery? I would like to have a way to communicate from Python to JavaScript
> in the client side, otherwise I really think we will not be able to use
> these projects in production.
>
> Hi Uri,

It's possible - but it depends on the project and the tooling they provide.
I know PyPy.js, for example, provides a JS/DOM bridge.

However, as I said in my last email, at the moment, this isn't the easy
path. Essentially, if you're asking the question "Is it possible", the
answer for all practical purposes is effectively "no". Technically, it's
possible, but you have to know what you're doing.

Yours
Russ Magee %-)

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

Re: pyjs - a compiler from Python to JavaScript

[Russell Keith-Magee]

Hi Uri,

There are multiple projects out there trying to bridge the gap between
Python and Javascript. PyJS was one of the first I was aware of, but to the
best of my knowledge, it hasn't been very active for the last couple of
years. Brython and Skulpt are two other projects - those two *have* been
kept up to date. There's also PyPy.js, which is the full PyPy interpreter
running in browser - which means you get CPython like performance inside
your browser.

Are they ready for production? That's another story. At the moment, I
wouldn't recommend it, especially if you're a beginner - but it's certainly
possible. However, you'd need to have a pretty good reason. You're going to
experience a lot of friction in the interface between the two languages, so
there would need to be a good reason for taking on that overhead.

Yours,
Russ Magee %-)

On Fri, Aug 7, 2015 at 7:00 PM, Uri Even-Chen  wrote:

> To Django users,
>
> Are you familiar with pyjs ? I saw the website and I
> see that the latest stable release is from May 2012. Is it possible to use
> pyjs to compile Python to JavaScript? Which versions of Python are
> supported? Are versions 2.7 and 3.4 supported? And is it possible to use
> Django (in the client side) and JavaScript frameworks such as jQuery,
> jQuery UI and jQuery plugins together with pyjs?
>
> Thanks,
> Uri.
>
> *Uri Even-Chen*   [image: photo] Phone: +972-54-3995700
> Email: u...@speedy.net
> Website: http://www.speedysoftware.com/uri/en/
> 
> 
>   
> > Speedypedia in Hebrew and English
> 
>
> --
> 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/CAMQ2MsHy4hwdxgZ8uXo36LtZrKZC_0GgjsGybcdbwpAP14AN5g%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 
https://groups.google.com/d/msgid/django-users/CAJxq84-KiCdRYtaVY_%3DFuuCSpb77GuG4P3vsyMSb083c7YWrZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Individual form element modification in Django

[Russell Keith-Magee]

Hi Rafer,

I think what you're looking for is the "attrs" argument on a form widget.

https://docs.djangoproject.com/en/1.8/ref/forms/widgets/#django.forms.Widget.attrs

That page has some examples showing adding a class to a field as a specific
example:

class CommentForm(forms.Form):
name = forms.CharField(widget=forms.TextInput(attrs={'class':
'special'}))
url = forms.URLField()
comment = forms.CharField(widget=forms.TextInput(attrs={'size': '40'}))

Yours,
Russ Magee %-)


On Wed, Jul 22, 2015 at 12:05 AM, Rafer Johnson  wrote:

> Hi Guys,
>
> I would like to know how I can apply unique identifiers to individual form
> elements. Currently I am trying to apply unique classes to individual
> inputs in a form and finding it impossible based on what I know about
> Django form helpers. I was trying to apply a unique background to each of
> two radio buttons and I had to use JQuery combined with the "for"
> information in the radio button to apply the style since I cannot add a
> class to each element.
>
> Would love to hear if there is another solution to this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/557b9695-0da7-469c-beea-659a2dd811a3%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/CAJxq84-R21sFvdCTBpCFHT%2BZJU73FVJ4n9sYFi6OV2mheMAszw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: SHOP APP

[Russell Keith-Magee]

On Tue, Jul 21, 2015 at 7:11 PM, dravid rahul  wrote:

> Hi can anyone please help me with this.. I am newbie to django.
>
> PLEASE FIND BELOW ATTACHMENT
>
> Thanks in Advance
> Dravid
>

Dravid - we're not going to do your homework for you. You've been given a
task for assessment purposes - the whole point is that you do the work
yourself.

We're happy to answer questions, but they need to be specific questions
about usage, not "can you do this for me".

Yours,
Russ Magee %-)

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

Re: Is there a plan to modernize Django-admin?

[Russell Keith-Magee]

On Sat, Jul 18, 2015 at 2:54 AM, xliiv 
wrote:

> Hi!
> Like the topic, though I don't mean only frontend.
> Backend could be also rewritten with for example class-based views and
> other stuff used in regular Django apps?
> Would it be a waste? I'm just curious what is your opinion. :)
>

Hi Tymoteusz,

As a volunteer project, what gets added to Django is whatever gets
contributed. We don't make plans and then execute on those plans. I'm not
aware of anyone who is actively working on a major rewrite/refactor of
Django's admin at the moment.

The state of Django's Admin is a topic that has been discussed many times,
over many years. I don't think you'd get any disagreement that there is
room for improvement; but it's also a big project. There have been a number
of third party projects that propose to replace Django's admin (most
notably django-admin2, but it's by no means the only project with this
goal).

The key thing here is that a new admin could be entirely constructed as a
third-party project. Django's existing admin doesn't do anything special -
it's "just" a Django app, like any other. If you're particularly motivated,
you could build your own Django admin using the tools that Django provides
(and, as of 1.8, documents as official, stable API).

For what it's worth, I've got my own crazy ideas about what a "new" Django
admin would look like, which I've hinted at at various conferences (hunt
down any of my conference talks about class based views). However, I'm not
likely to get any time soon to look at this as a project - I've got plenty
of other yaks that I'm shaving at the moment :-)

Yours
Russ Magee %-)

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

Re: Have a problem with a first Django App due to the Web Tutoral

[Russell Keith-Magee]

Hi,

The error message by itself doesn't give us a lot to work with - it's not
an error I'd normally expect to see while doing the tutorial.

My first guess would be that there is something corrupted in your Django
install - this might happen if you've got multiple versions of Django
installed, or if you've installed one version over the top of another.

Another possibility is that there is something wrong with the 1.8.3 release
- it *should* be a stable release, and I wouldn't expect to see a bug like
the one you describe, but it's only been out for a day or two, and stranger
things have happened in the past.

So - my first suggestions:

 * Completely uninstall Django, and confirm that it's uninstalled. Or, if
you're using a virtualenv, create an entirely new one. Then re-install
Django.

 * If that doesn't work, try installing Django 1.8.2 (pip install
django==1.8.2) to see if that makes a difference.

If neither of those two work, we're going to need to see some more context
of that error message - the full error traceback, for example.

Yours,
Russ Magee %-0



On Fri, Jul 10, 2015 at 9:39 PM, Happy Data Scientist <
happydatascient...@gmail.com> wrote:

> Dear Friends !
>
> I have an error when I tried to develop my first Django App due to the Web
> Tutoral:
> https://docs.djangoproject.com/en/1.8/intro/tutorial02/
>
> The error is  "ImportError at /admin/" -- cannot import name
> 'resolve_url'" for the address "http://127.0.0.1:8000/admin/";
> The Django version is 1.8.3
>
> Could you help me to resolve this issue ?
>
> Thanks ahead
>
> --
> 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/eac824c9-4898-440a-8479-81f846574a47%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/CAJxq84-Ro%2Bco-X4n%3DuQ%2Bfa97OgKmJsEZNS%3DZ4GsgNOG_f0gqCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django model for non web applications

[Russell Keith-Magee]

On Thu, Jul 2, 2015 at 12:50 AM, Jeff Fritz  wrote:

> I'm fairly new to Django and making my way through the tutorial.
>
> Knowing what I've learned so far, I'd like to explore using
> django.db.models.Model in a non-web application. I'd like to take the
> entire model layer and use it for database access in a standalone,
> multithreaded python 3.4 application. It is not a web application. I would
> like to be able to take advantage of the migration capabilities in
> manage.py.
>
> Questions:
>
> 1. Is it as simple as adding `from djanago.db import models`? Would this
> bring in any unnecessary django packages/modules, considering I will not be
> developing a web application, not using views, templating, etc?
>

It's *almost* this simple - you will also need to configure your Django
environment before you start making database calls. If you're looking to do
this in a *completely* "non-web" way, this probably means a call to
settings.configure(); details here:

https://docs.djangoproject.com/en/1.8/topics/settings/


> 2. Is the django model layer thread safe? Specifically, when using sqlite3
> as a back end?
>

It should be - after all, web servers are frequently multi-threaded.
SQLite3's performance under multithreading, however, might leave something
to be desired.


> 3. Are there other clean ORM/database model layer frameworks/packages that
> I should consider for python 3.4?
>

The other obvious candidate would be SQLAlchemy; it's a perfectly fine ORM
- without any of the other web framework overhead. It's a lot more like a
"SQL building toolkit" than Django's ORM - whether this is a good or bad
thing depends on your own preferences and use case.

Yours,
Russ Magee %-)

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

Re: Django 1.8 Transaction Begin

[Russell Keith-Magee]

Hi Katarzyna,

I'm not sure what gave you the impression that Django doesn't support
transactions - there's a whole section in the documentation about this very
topic:

https://docs.djangoproject.com/en/1.8/topics/db/transactions/

You don't explicitly execute a "BEGIN" statement, but you can definitely
put code into a transaction.

Yours,
Russ Magee %-)


On Wed, Jun 17, 2015 at 5:41 PM, Katarzyna Łabędź  wrote:

> Hi!
>
> As far as i know Django 1.8 does not support BEGIN transaction for mysql.
> Is there a way to invoke this?
> How to invoke BEGIN Transaction in a raw sql? I cannot find it in
> documentation...
>
>
>  --
> 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/0f0adf0f-bfca-4aae-9bc5-64cb5ee1ee18%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/CAJxq849swkNm22tGohYh_%2BHyBQqzoysBvffNgQi0RmXeh_uWNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django users Group admin

[Russell Keith-Magee]

Hi Eike,

I'm an admin; feel free to mail me any list admin requests.

Yours,
Russ Magee %-)

On Friday, June 12, 2015, Eike Post  wrote:

> Hello Django users,
> does anybody of you know how to get in touch with the Django user group
> admin?
> I tried via contact admin and tried emailing to these emails:
> django-users+ad...@googlegroups.com
> 
> django-users+ow...@googlegroups.com
> .
> But nothing worked so far.
> Any suggestions?
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+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/cd29c165-2c18-48a2-84d1-efcb31473a25%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/CAJxq84-MRUX3idi1uAFJxy8sWKMaum9on4qSOOn%2BPR8ODdF9qQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to get get-pip.py

[Russell Keith-Magee]

On Fri, Jun 5, 2015 at 4:51 PM, Steve Burrus 
wrote:

> Okay Monte I will certsainly "man up" and start over and try to do what
> you said.
>

Hi Steve,

A quick aside: I'm sure you didn't intend any offence, but using language
like "man up" isn't something we support in the Django community. We aspire
to being an open and inclusive community; if you're participating in Django
community spaces, you're expected to adhere to the Django Community Code of
Conduct:

https://www.djangoproject.com/conduct/

There's nothing inherently masculine about software development.
Expressions of overt masculinity and "bro" culture don't improve the
clarity of your message, and are direct contradiction of our community
goals of inclusivity and diversity.

Please don't use turns of phrase like this in future.

Yours,
Russ Magee %-)

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

Re: Embeding HSQLDB in a standalone App

[Russell Keith-Magee]

On Tue, May 19, 2015 at 7:49 PM, Kapil Solanki 
wrote:

> Hi All,
>
> I need to embed hsqldb in my project. I have been looking for solution
> online but couldnt find a proper one.
> BDW am new to django and python so its bit difficult also for me to search
> the right solution.
> Please suggest if there is any hsqldb llibraries or any module for django
> app which i can include and start performing db operation in my app.
>

My guess - you'll need to use the JDBC interface. There are several JDBC
libraries for python; I have no idea how robust they are, but if there
isn't a well known Python API for HSQLDB, using JDBC will be your best
option.

Yours,
Russ Magee %-)

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

Re: Scaling/Parallel patterns for a View executing complex database transaction

[Russell Keith-Magee]

On Thu, May 14, 2015 at 6:03 PM, Me Sulphur  wrote:

> Stack: Django 1.7 + Postgres 9.3 + Linux (No caching)
>
> Our application has a view which is called/executed very frequently. The
> view receives, parses and responds a JSON.
>
> In between request and response, there are about 3-5 inserts and around
> 1200-5000 look ups depending upon some if..else business logic. At around
> 2-4 seconds the view is very slow.
>
> However, a lot of the look ups (which are the bottlenecks) can be
> parallelized. But I do not know how can I do the same within a
> request-response cycle.
>
> If it was a web UI, I could use celery+polling, since it a machine-machine
> API call, the parallelisation has to be possible within a View's life cycle.
>
> If parallelisation is not possible, what alternatives do I have for
> scaling and reducing response time.
>
> The short answer is "it depends".

There isn't a single answer - everything will depend on the specifics of
your problem space. All I can offer is some vague suggestions of places you
might be able to look for some extra speed.

 * Do you *really* need to do 1200-5000 lookups? It's faster to do 1 query
returning 10 rows than 10 queries returning 1 row each. Can you optimise
the queries on the database to minimise the number of queries needed?
Depending on circumstances, it may even be faster to do 1 query returning
15 rows, and then post-process in the view to throw away the 5 rows you
don't need.

 * Better still - can you optimize the database structure so that 1200-5000
calls aren't needed? Modern relational databases are *really* good at query
optimisation - if you give it the right query, and the right database.

 * Can you work your algorithm another way? In a previous job, I worked on
a tool that would look at a database of thousands of news articles received
in a given day, and then, for each of thousands of users, work out which
articles were "interesting" so they could be sent out in a daily alert
email. The obvious algorithm for this is "for user in users:
find_articles(user)" - but, for a variety of reasons, it turned out that
doing "for article in articles: find_users(article)" was almost 2 orders of
magnitude of faster. The less obvious algorithm allowed much greater
caching, and massively cut down the number of queries that were required.
The tradeoff was a lot more memory (memory vs speed is almost always the
tradeoff), and it wasn't only faster if you computed the results for *all*
users at the same time - but this was an daily offline process, so these
were limitations we were willing to accept.

 * To that end - is there anything that can be precomputed? Can you cache
pieces of the response? Is there anything you can put into a memory store,
rather than the database. Databases are great, but if you have a small
amount of frequently re-used, easily keyed data, it may be better to put
that data into a location where it can be obtained quickly, rather than
hitting the database.

 * If you *must* parallelize, and your algorithm is conducive to it,
threads are probably your best option - work out what part of your
algorithm can be parallelized, and put each part in a thread, and merge the
results once all the threads complete. If you're on Python 3, look into the
concurrent.futures module (or the "futures" module if you're on Python 2)
to help make this easier to manage. However, threads aren't magic fairy
dust - my "limited knowledge of your situation" guess is that
parallelization won't help you. If you've got a frequently executed view
doing thousands of database calls, I'm going to guess the database is
already a bit of a bottleneck; adding 10 threads per request is going to
increase the database load and make performance *worse*, not better, and if
it's a high traffic view, at some point, you're going to hit the limit of
the number of threads your server can handle.

 * Lastly, I'd challenge your assertion that this can't be done using a
celery + poll approach because it's a machine API. The fact that it's a
machine consuming the API doesn't matter; it's just a matter of what the
machine consumes. The public API for a "long running data processing
service" should be a 2 call API: (a) submit a processing request, and (b)
check the status of a specific processing request. If a human is consuming
this API, it can be put into a nice single-page app with an AJAX call
checking the status of the request. If it's a machine, you can make exactly
the same calls; you just treat it as a sequential sequence of calls with a
"while not finished: poll(); sleep(5)" loop. Of course, changing the API
style won't make your algorithm run any faster - it will just take the load
off your web server and allow you to offload processing to other servers.

I hope some of this helps.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an

Re: Invalid HTTP_HOST, can someone explain why I am getting this?

[Russell Keith-Magee]

Is there a setting to turn of a warning that someone is attempting to
access your site in a potentially malicious way? No.

When you get a warning like this, you investigate the cause, and fix the
problem. You don't just silence the warning.

Yours,
Russ Magee %-)

On Thu, May 14, 2015 at 3:44 AM, frocco  wrote:

> Thanks for getting back to me.
> I am on django 1.5. Is there a setting I can use to avoid getting these
> emails?
> I get at least 5 a week.
>
>
>
> On Tuesday, March 17, 2015 at 6:58:00 PM UTC-4, Russell Keith-Magee wrote:
>>
>> Hi,
>>
>> It's possible that you're getting this error for the exact reason that
>> the check was added - someone is submitting requests to your site with a
>> manipulated HTTP_HOST header. This may not be malicious - it could just be
>> a badly configured robot making web requests.
>>
>> It might also point at a problem with your hosting provider - especially
>> if you're sharing an IP address with g3suprimentos.com.br, or if
>> g3suprimentos.com.br once had the same IP that you're currently using.
>>
>> Without more details, it's hard to say for certain. But is someone trying
>> to hack your site? Almost certainly not. If you were being hacked, you
>> wouldn't have described the problem as "I see this error from time to time"
>> - you would have said "I just received a thousand of these in the last 10
>> minutes". Attackers aren't noted for their subtlety - they will generally
>> try every possible backdoor and exploit that they know of, all at once.
>>
>> Yours,
>> Russ Magee %-)
>>
>> On Tue, Mar 17, 2015 at 11:45 PM, frocco  wrote:
>>
>>> I am concerned because I have a value in ALLOWED_HOSTS, but it is not
>>> this value.
>>>
>>>
>>> On Tuesday, March 17, 2015 at 9:17:15 AM UTC-4, frocco wrote:
>>>>
>>>> SuspiciousOperation: Invalid HTTP_HOST header (you may need to set
>>>> ALLOWED_HOSTS): www.g3suprimentos.com.br
>>>>
>>>> I keep getting this error from time to time.
>>>>
>>>> Is someone trying to hack my site?
>>>>
>>>> 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...@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/5550dde0-4230-4068-a8b5-196f0bd844fc%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-users/5550dde0-4230-4068-a8b5-196f0bd844fc%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> 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/ab908cd5-8c5b-4d6e-9033-80fca60415f7%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/ab908cd5-8c5b-4d6e-9033-80fca60415f7%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CAJxq84-iGOycH2zn2T9mCLUuTmSOyHdquFHp9Duj39xqZ03dag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Leveraging the ORM for very complex queries

[Russell Keith-Magee]

Hi Suriya,

It sounds like you're looking for raw SQL queries:

https://docs.djangoproject.com/en/1.8/topics/db/sql/#performing-raw-queries

This allows you to issue a SQL query in SQL, rather than trying to bend the
ORM to meet some complex query requirement.

You can't compose a raw query like a normal Django ORM query (e.g., you
can't add a filter clause to an raw query), but a raw query object behaves
exactly like queryset when it returns results - it is iterable, it returns
full Django objects, and so on.

Yours,
Russ Magee %-)

On Sun, May 3, 2015 at 9:22 AM, Suriya Subramanian  wrote:

> Hello,
>
> I have to write some complex SQL queries that I am unable to express using
> the ORM. I construct these complex queries by writing a few simple ORM
> queries, getting the SQL using QuerySet.query and combining them with
> various SQL operators manually. These hand-crafted queries are not very
> flexible because it is very easy to modify the final SQL.
>
> My question: Is there a way to programmatically construct the complex
> queries. I see that I can get the generated SQL and parameters by invoking
> SQLCompiler.as_sql(). Can I invoke as_sql() on the individual query sets
> and then construct the complex query? What are some gotchas that I need to
> watch out for?
>
> Thanks,
> Suriya Subramanian
>
> --
> 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/b4465893-6d08-4ed3-babd-1f6e0f0f52ab%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/CAJxq8492YZY_Px2o1nEKzF3-F3TBsv6ZGzs71zhkNmAGoRoNkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to rename crfstoken

[Russell Keith-Magee]

Hi Vermus,

Yes, the form value is currently hard coded.

I can't think of any particular reason that this shouldn't be configurable
though. If you're looking to get into Django development, it would be a
fairly easy feature to contribute - there isn't that much code required to
implement the change, and the docs and tests will be pretty straightforward.

Yours,
Russ Magee %-)

On Tue, Apr 28, 2015 at 5:27 PM, Vermus  wrote:

>
> ok, i renamed cookie name,
> but what about rename input name "csrfmiddlewaretoken" of {% csrf_token %}
> ?
>
> as i see it is harcoded?
>
> http://stackoverflow.com/questions/27087626/rename-csrfmiddlewaretoken
>
>
> вторник, 28 апреля 2015 г., 11:28:36 UTC+3 пользователь Vermus написал:
>>
>>
>> Oh, I missed this setting, stupid (i think, it is new for me, i'm using
>> django since 1.0)
>> thank you!
>>
>>
>>>
>>>  --
> 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/52f0c198-fb37-4389-9da8-34ce18cb6625%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/CAJxq84-NvvNd%3Dji-eE5L_C0Owz0MGrjCvu8Ox_X0q0%3DoiBxRFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to rename crfstoken

[Russell Keith-Magee]

Hi Vermus,

Calling this a security "breach" is a bit inaccurate; but I certainly agree
that it is good practice to make the framework undetectable from the client
side.

That's why there's a setting that does exactly what you suggest:

https://docs.djangoproject.com/en/1.8/ref/settings/#csrf-cookie-name

Yours,
Russ Magee %-)


On Tue, Apr 28, 2015 at 3:27 PM, Vermus  wrote:

> Hi, i found, that my site is detected by
> http://trends.builtwith.com/framework/Django-CSRF by crfstoken header.
> I think, it's security breach, when users know what framework is used on
> server side.
> There must have such web server tuning, that no one can detect framework
> and server side programming language.
>
> --
> 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/768a1d03-e749-428a-8094-4a2d2f27e873%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/CAJxq84_eWoKaAwpYWeGkMa%3DZMFNAh3Qxe0REqBtydDRPYRpBmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What happens if pk value gets too big?

[Russell Keith-Magee]

On Sat, Apr 4, 2015 at 6:25 AM, Mike  wrote:

> Hi,
> Is there risk of getting too big PK value while adding and deleting rows
> for long time in same table?
> -Mike
>

It depends on what you mean.

This code:

while True:
obj = MyObject.objects.create()
obj.delete()

won't pose any problem at all. The primary key for each obj will
*generally* increase with each new object that is created - but it's not
*guaranteed* to increase. After a while, old, lower primary key values will
be re-allocated to new objects. Exactly how and when this is done depends
on the database. In short - don't assume that an object A created after
object B will have a higher primary key value.

However, if you remove the "obj.delete()" line, and you just keep creating
new objects, you will *eventually* run out of available primary keys. When
this happens will depend on what data type your primary key has. PostgreSQL
and MySQL both default to 32 bit primary keys, so that means you can create
over 2 billion objects before you run out. If this isn't enough, you can
make your primary key a BIGINT, which will give a limit of 9 quintillion
objects. If that's not enough... well... you need to stop creating a
database row for every grain of sand on the beach :-)

Yours,
Russ Magee %-)

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

Re: Multiple Django projects using the same database

[Russell Keith-Magee]

On Mon, Mar 30, 2015 at 10:20 AM, Ien C.  wrote:

> Thanks Russ!
>
> Good point about the validation logic. Will definitely keep that in mind.
> And yes, my basic approach here is the same code base working on different
> subsets of data by default, with the ability for data to be optionally
> "seen" by both sites as needed.
>
> One more question: there's no need to keep settings.SECRET_KEY the same
> across the sites, is there? In the context of this question, someone told
> me that SECRET_KEY is used for hashing db reads/writes, but that doesn't
> sound right to me and I don't see anything about that in the docs. The two
> sites can (and should) have different SECRET_KEY values, right?
>

Depends on what your "secret" sharing policy is between the two sites. If
you want a truly shared login (as in - log into site A, login is recognised
on size B), or shared session payloads, you would need to have a shared
SECRET_KEY (along with some other cookie domain tweaks). However, if
they're independent sites, and you explicitly *want* someone to log into
site A and site B separately, then different SECRET_KEYs are advisable.

I don't know what your "someone" meant about hashing db read/writes -
unless they were referring to the session table. It certainly isn't
something that is applied to *all* DB read/writes, or would prevent data
written with one site from being read by the second.

Yours,
Russ Magee %-)

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

Re: Multiple Django projects using the same database

[Russell Keith-Magee]

On Mon, Mar 30, 2015 at 12:14 AM, Ien C.  wrote:

> Hi everyone,
>
> I'm hoping to confirm my understanding on how to deploy multiple Django
> websites using the same database, using postgres and gunicorn/nginx.
>
> Doing this seems to me as simple as:
> 1. Creating a copy of the Django project in its own directory, with its
> own settings.py etc.
> 2. Keep the same settings.DATABASES the same, i.e. pointing to the same
> postgres server.
> 3. Deploy the new site as if were a standalone site, e.g. separate
> /etc/nginx/sites-available/new-site-name.conf etc.
>
> Of course doing the above wouldn't be very useful unless the two sites did
> something different. For instance, to have them by default work on
> different subsets of the data, I could use the Django sites framework,
> where the CurrentSiteManager restricts queries to data associated with the
> specific site baed on settings.SITE_ID. The two sites could still access
> all data using standard model managers, and there would be no problem
> having models associated with one site link to models from another site via
> related fields as normal, as long as the model's default manager could see
> all data.
>
> Core Django tables like User and Permissions would be shared between the
> two sites, so if a user has access to one site, they will have access to
> the other site.
>
> As for race conditions, there are no particular new issues raised by two
> sites sharing the same database, i.e. race conditions could happen but it's
> no different than with multiple requests on a single site.
>
> Have I got all that right? Anything I'm missing? Is it really as simple as
> just having two Django sites point to the same database via
> settings.DATABASES?
>
> Thanks,
> Ien
>
> Hi Ien,

You've got it right - it's exactly that simple.

Remember, even if you've only deployed a single website, you're still going
to have multiple threads/processes accessing that site - your web server is
inherently multithreaded. All you're doing by deploying 2 sites is
introducing a way by which half of those threads/processes will be using a
different chunk of code to evaluate requests.

The only caveats you didn't cover that I can think of relate to
inconsistencies in the two different sites interacting with the data in
different ways. If you've got site logic that imposes validation conditions
or something like that, and the two sites have different validation logic,
there's no inherent guarantee that an object created on one site will meet
the validation requirements of another. However if you make sure all the
validation logic is common between the two sites, and the only thing that
is different is the subset of data available, or the presentation style of
that information, then you shouldn't hit this sort of problem.

Yours,
Russ Magee %-)

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

Re: Re-run only tests that failed last time

[Russell Keith-Magee]

Hi Gergely,

One option is to use a test suite GUI tool, like cricket:

http://pybee.org/cricket

Cricket lets you view your entire test suite as a tree, select subsets of
the suite to run, see test results as the suite executes, and re-run the
failures from the previous execution.

Yours,
Russ Magee %-)


On Tue, Mar 24, 2015 at 6:27 PM, Gergely Polonkai 
wrote:

> Hello,
>
> I have a pretty extended test suite for my application, which can run for
> about 15 minutes. Now when I introduce an error, I will be notified of it
> pretty late, and a one-liner fix needs another 15 minutes to check. Of
> course if only one of my tests fail, I can add the name of the test case as
> a parameter to manage.py test, but in case of many failures it’s pretty
> hard to do the same.
>
> Is there a way to run only the tests that failed last time, even if I have
> to install a separate app/module for that? A quick Google search gave me no
> usable results.
>
> Best,
> Gergely
>
> --
> 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/CACczBU%2B-SR3uASD_eQc_c%2BKFp%3DvCgaWga6pfUgA%2BJHr5HgkCHQ%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 
https://groups.google.com/d/msgid/django-users/CAJxq84-hZn2VOe_dHRS63BXTmFJ8h3pbdsuKgQE1uFJo6csBZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to supply parameters to "python manage.py syncdb" from a script?

[Russell Keith-Magee]

On Sat, Mar 21, 2015 at 5:25 AM, Dan Dong  wrote:

> Hi,
>   Does anybody know how to supply the input parameters to "python
> manage.py syncdb" from a script? E.g, to set the the followings parameters:
>
> Would you like to create one now? (yes/no): yes
> Username (leave blank to use 'root'):
> Email address: x
> Password: xx
> Password (again): xx
>
> You don't - and that's by design.

If you're putting a password into a script, then that script is in plain
text, and so is your password - so you've just lost your security.

So - you don't pass input parameters to the script. You run the script with
the --noinput flag, which will prevent the script from prompting for user
input.

If you want to have an initial user in your database after syncdb, put that
user's data in a fixture, and load the fixture as part of the script. The
fixture will contain the password in a hashed format, so the password will
be protected.

Yours,
Russ Magee %-)

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

Re: Django 1.6's lifespan for security updates?

[Russell Keith-Magee]

On Thu, Mar 19, 2015 at 2:27 PM, Mike Dewhirst 
wrote:

> Maybe ... some effort to solve the infrastructure issue would make it
> worth kickstarter funding.
>
> A couple of colleagues are pushing me towards Docker as a packaged Python
> 3.4 environment but that is beyond my interest atm.
>
> I am running a dedicated production server on Ubuntu 14.04 which more or
> less forces me to stick with Python 2.7. I would like to move to Python 3.x
> using virtualenv but I don't want to mess with stuff which is working.
>
> Maybe a really nice solution would be a kickstarter project to develop a
> deployment tool to create a predictable, supportable modern environment on
> "old" boxes and to vaccuum up the existing Django sites running on bare
> metal.
>
> In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv
> approach would be covered by standard Ubuntu support. I have only glanced
> at Docker so I don't know how valid that might be.
>

Docker isn't needed for any of this, especially on Ubuntu 14.04. Python 2
and Python 3 can co-exist, and Python3.4 is part of the standard repo for
Ubuntu 14.04. Even if it wasn't, you could install Python to a user-space
directory, and create a virtualenv based on *that* version of Python.

However, in a broader sense, I think you'll find that the audience of
people who need this tool are almost by definition the set of people who
wouldn't be able to use it.

If a company is locked into Python 2.6, it's because they're on a
Enterprise Supported Version (tm) of some operating system; in that sort of
environment, installing and using *anything* that isn't provided by the
vendor is a non-starter. Even if a tool *was* developed, you'd need to get
it deployed in-channel - and that could take years... or you could just
upgrade your system :-)

FWIW: This is the exact type of problem that RedHat software collections
are designed to fix - RHEL wore a lot of flack for being so pathologically
behind the times (the Python interpreter being one key component). RedHat's
response has been to introduce software collections - an officially
mandated set of tools that can be updated much more regularly, official
blessed by the manufacturer.

https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/

Obviously, this won't help if you're not on RHEL6 or 7 - but it's an
indication that some enterprise vendors are listening.

Yours,
Russ Magee %-)

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

Re: Django 1.6's lifespan for security updates?

[Russell Keith-Magee]

On Thu, Mar 19, 2015 at 12:05 PM, James Bennett 
wrote:

> On Wed, Mar 11, 2015 at 3:54 PM, Tim Graham  wrote:
>
>> Having managed the last few security releases for Django, I'll say it's
>> one of my least favorite tasks and I'm quite looking forward to dropping
>> support for 1.4 (which supports Python 2.5) and 1.6 (Python 2.6). But, if
>> there's sufficient interest that we could raise funds to support this
>> effort outside of my normal duties as Django fellow, there's a chance you
>> could convince me to continue backporting patches and preparing releases
>> for these versions. I'm not quite sure how the logistics of such an
>> arrangement would work, but just thought I'd throw the idea out there and
>> see if anyone is ready to back the effort financially. I'd want the
>> endorsement of the core team before finalizing anything.
>>
>
> Way, way, *way* back in the day, there was unofficial bugfix support for
> pre-magic-removal versions of Django run on the basis of "some people who
> need it step up and do all the work". It was solely done in SVN and never
> involved issuing new releases, so anyone running off the maintenance branch
> had to just update their checkout whenever a fix landed in it.
>
> I'm not opposed to allowing that again -- and in fact I was one of the
> people who did extended maintenance for pre-m-r Django because my employer
> at the time needed it -- but I think we should carefully consider how it's
> going to work before trying it, since we no longer have the ability to give
> partial commit bits
>

Agreed that this is an approach we could take - but I don't think the lack
of a partial commit bit isn't a major issue IMHO.

At a technical level, Git gives anyone the ability to fork Django's
repository. There's no *technical* reason that someone couldn't maintain a
1.6 branch *right now* - the only restrictions are that they couldn't call
that repository official (as per BSD licensing terms), and they wouldn't
have access to security patches until everyone else did.

However, both of these are solvable problems.

The only thing that makes Django's Github repository "official" is because
the core team says it is. If someone wants to take on the task of back
porting all the security patches to 1.6, we (as a project) can point to
that repository if we want. If we're interested in doing 1.6 support as an
"unofficial" subproject, then it seems appropriate to me that the
repository *isn't* Django's core repository; picking a third-party vendor's
repo sounds like the right way to do it.

As for getting the patches ahead of time - I'd be more than happy for an
appropriately qualified and trustworthy individual/company to be added to
the security pre-notification list.

So - it really just comes down to someone having the enthusiasm to maintain
the branch. Christian has been around the Django project for a long time
(he was a contributor to Django Evolution from very early on, and took over
maintenance of the project when I moved on). If he's got a commercial
interest in continued 1.6 support, and he can spare a couple of hours to do
a backport when a security issue is announced, I'd have no problem adding
him to the pre-notification list, and adding some documentation pointing at
his fork of Django as an "unofficial 1.6 repository". If Christian hasn't
got the time to do this, but he (and/or anyone else) can throw some funds
at Tim, Tim is already on the security notification list.

Yours
Russ Magee %-)

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

Re: Invalid HTTP_HOST, can someone explain why I am getting this?

[Russell Keith-Magee]

Hi,

It's possible that you're getting this error for the exact reason that the
check was added - someone is submitting requests to your site with a
manipulated HTTP_HOST header. This may not be malicious - it could just be
a badly configured robot making web requests.

It might also point at a problem with your hosting provider - especially if
you're sharing an IP address with g3suprimentos.com.br, or if
g3suprimentos.com.br once had the same IP that you're currently using.

Without more details, it's hard to say for certain. But is someone trying
to hack your site? Almost certainly not. If you were being hacked, you
wouldn't have described the problem as "I see this error from time to time"
- you would have said "I just received a thousand of these in the last 10
minutes". Attackers aren't noted for their subtlety - they will generally
try every possible backdoor and exploit that they know of, all at once.

Yours,
Russ Magee %-)

On Tue, Mar 17, 2015 at 11:45 PM, frocco  wrote:

> I am concerned because I have a value in ALLOWED_HOSTS, but it is not this
> value.
>
>
> On Tuesday, March 17, 2015 at 9:17:15 AM UTC-4, frocco wrote:
>>
>> SuspiciousOperation: Invalid HTTP_HOST header (you may need to set
>> ALLOWED_HOSTS): www.g3suprimentos.com.br
>>
>> I keep getting this error from time to time.
>>
>> Is someone trying to hack my site?
>>
>> 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/5550dde0-4230-4068-a8b5-196f0bd844fc%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/CAJxq849VOSnDfv3WCQhBtHTC41ANiLPR9C3TenYub3yh4Nxf2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoKites Virtual Classroom

[Russell Keith-Magee]

Hi Barclay,

Welcome to the community! If you want to know anything about the Django
Project's involvement in Google Summer of Code, our wiki page is here:

https://code.djangoproject.com/wiki/SummerOfCode2015

If you've got any more questions, let us know.

Yours,
Russ Magee %-)

On Tue, Mar 10, 2015 at 2:32 PM, Barclay Koin  wrote:

> *Hi am Barclay from Nairobi Kenya currently a student at Dedan kimathi
> University of Technology. Am applying for  GSoKites Virtual Classroom
> and would like to a part of the growing community.*
>
> --
> 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/a166e492-fe8a-4aff-aa24-01c778d4f10c%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/CAJxq84_HHv8daJEYrf%2B44KFSCLJ0iYawu9Q4fPqna_USR2dU4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Choose Database based on geolocalization]

[Russell Keith-Magee]

On Sun, Mar 8, 2015 at 9:15 PM, 'Petros Moisiadis' via Django users <
django-users@googlegroups.com> wrote:

> On 03/08/2015 01:42 AM, Russell Keith-Magee wrote:
> > Hi Xina,
> >
> > The short answer is "not easily, and not within Django".
> >
> > Django's DB Routers don't contain any detail about the request, so
> > there's no ability to geolocated the requesting IP for routing
> > purposes. For the record, this is because Django is a general purpose
> > toolkit - there's no guarantee that a request to access the DB has
> > come as a result of a HTTP request - it might come from a standalone
> > script, which won't have an IP address.
> >
>
> Django's DB routers have the notion of 'hints'. So, theoretically, a
> hint with the HTTP request object could be passed to a db router (when
> access to a database comes as a result of an HTTP request) or not passed
> at all (if the database request is triggered by other means, e.g. a
> standalone script). I am not saying that Xina's use case would be served
> better with such an implementation though. Just pointing out that, in
> theory, there should be no inherent restriction in Django supporting this.
>

Yes, DB Routers support hints. How are you planning to inject those hints
into the router? Router arguments aren't exposed to the end user when you
do a query - they're automatically generated by the query, and only include
details about related objects in the query.

Yours,
Russ Magee %-)

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

Re: [Choose Database based on geolocalization]

[Russell Keith-Magee]

Hi Xina,

The short answer is "not easily, and not within Django".

Django's DB Routers don't contain any detail about the request, so there's
no ability to geolocated the requesting IP for routing purposes. For the
record, this is because Django is a general purpose toolkit - there's no
guarantee that a request to access the DB has come as a result of a HTTP
request - it might come from a standalone script, which won't have an IP
address.

So - you'll need to look further up the stack to do this sort of routing.
My suggestion would be to look at the web server level.

The simplest approach would be to deploy multiple "versions" of your app on
different subdomains - "asia.example.com, us.example.com, europe.example.com",
and rely on users to pick the right domain. Each version would be running
exactly the same code - but they would each have a different settings file,
pointing to the asia database, us database and so on.

A more complex approach would be to use IP-based routing at the web server.
NginX has plugins like GeoIP to redirect traffic based on the IP of the
requesting user. In this configuration, you'd still have multiple servers,
but the NginX server would be directing traffing from the root "example.com"
to the right geolocated server.

Yours,
Russ Magee %-)




On Sun, Mar 8, 2015 at 4:06 AM, xina towner  wrote:

> Hi,
>
> is there any possibility that we could select the database to which route
> a request of a user depending on the geolocalization of the client? Or the
> user country?
>
> I've check some documentation of the dbrouters, but I am concerned that if
> a user travels to another country he is going to be routed to the wrong
> database.
>
> Does anybody have know how to solve this issue?
>
>
> --
> Gràcies,
>
> Rubén
>
> --
> 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/CANGESS-w7ctv9AeGkbBymuhLgYAdEZqcDSrkwPCd3Rw8-6Rkjw%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 
https://groups.google.com/d/msgid/django-users/CAJxq8490NDW4WLjEQ%3DLn_8yh1MY-Z-hKHATkR6aS6ZzickiqHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Embedding a compiler to my web page

[Russell Keith-Magee]

If you're going to be compiling code, you almost certainly don't want to be
using subprocess for this. A view should be able to return in milliseconds.
Very few native code compilations are going to be complete in milliseconds.

What you should be doing is treating the compilation step as a compilation
task:

 1) User submits code for compilation. This creates a compilation task in
state "Pending"

 2) A second process, completely external to your web server sits waiting
for new "pending" tasks; when a new task arrives, it is taken off the
queue, and moved to a "compiling" state.

 3) The user has the ability to refresh the status of the tasks they have
submitted. This could be auto-refreshed, or left as something that the user
can hit reload to see the current state.

 4) When the compilation completes, the state moves to "Done", and the user
can see the result.

This external process is called a task queue; there are lots of ways of
managing this; two relatively easy options are RQ (a simple Redis-based
queue) and Celery (a more complete option; harder to get going, but more
reliable and configurable under heavy load).

Also - as a security warning - if you're going to be exposing the ability
to compile code on the internet, be prepared to be exploited. Compilers can
do lots of things, and you're going to be giving  permission to compile
arbitrary code to anyone who can submit a compilation task. You will need
to be *extremely* careful about how you set up the compilation tools to
make sure they are adequately sandboxed.

Yours,
Russ Magee %-)

On Sun, Mar 8, 2015 at 12:08 AM, luis zarate  wrote:

> You should want to read about subprocess
>
> https://docs.python.org/3.4/library/subprocess.html
>
> Install your favorite compiler and call it with subprocess as a comand
> line program.
>
> 2015-03-07 9:01 GMT-06:00 Snehasish Sen :
>
> How can I embed a c/c++ compiler to my site which can host a programming
>> competetion
>>
>> --
>> 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/2a2fae63-cb65-41e1-af5c-d67d30c21eb8%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> "La utopía sirve para caminar" Fernando Birri
>
> --
> 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/CAG%2B5VyM2yKJDZXLnndEHn%3DoVn1siTeVOeh5YsNuh5hwan2VFLw%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 
https://groups.google.com/d/msgid/django-users/CAJxq84-h-6L1hO%3Dq-tt237Tnq87Xq4d2Kzcms3%2B--2RYkjCCMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Research: Translations od documentation

[Russell Keith-Magee]

On Thu, Feb 26, 2015 at 9:51 PM, Tomáš Ehrlich 
wrote:

> Hi Tim,
> I'm aware that it's possible to translate Django documentation. I also
> know that it's translated to french only.
>
> My question is one step behind: Does it makes sense to translate Django
> documentation and (more important) keep it updated? Would anyone use it? Is
> English language the common tongue for programmers? Why is Django docs
> translated to one language only? There isn't enough translators or users
> just don't find it useful?
>
> I asked the same question in Czech django user group and most of them
> agreed that it doesn't make sense to translate whole Django documentation.
> It would make sense to translate materials for beginners, like tutorials,
> django book, etc.
>
> So, at the moment, I don't care about the *tool* or *process*. I'm trying
> to figure it out if there is some kind of motivation to do this stuff.
>

You're going to be in a much better position to judge this that we will.
You're in the middle of a Czech language community; if you were to spend a
week of volunteer time translating the tutorial, do you think it would help
enough people in that community to make the exercise worthwhile?
Ironically, the one place you're *not* going to get a good answer is this
mailing list - because the audience for your translation aren't going to be
able to read it.

>From the perspective of a native English speakers, it makes sense to me
that people would want to have translations in their native languages. What
I don't know is how many Czech speakers speak English well enough that
translating the tutorial wouldn't yield any real benefit. My usual
experience of non-English speaking Europeans is that they speak better
English than I do :-) - but I don't know if that's just selection bias, and
I'm not talking to the ones that don't speak English.

So - it really comes down to how you want to spend your efforts, and your
understanding of the needs of your language community.

Yours,
Russ Magee %-)

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

Re: Python / Django slow ? Deciding my next technological stack

[Russell Keith-Magee]

On Wed, Feb 25, 2015 at 7:30 AM, Benj  wrote:

> Hi,
> i'm going to invest lots of time and energy in various web projects
> (mostly community web sites), and want to pick up a language / framework
> and invest heavily on it.
> I've spent a lot of time evaluating the various options, and narrowed my
> choice to 2 stacks: C sharp asp.net  MVC or Python / Django.
>
> I'm more attracted to Python / Django combo, because of the Python
> language, and high level framework Django. I really want to use these.
> My only concern is speed. I read that Python can't run concurrent tasks,
> is this true ? So a multi-processor with hyperthreads won't benefit the
> stack and even slow it down ?
> I have no clue how this translates in reality, but should I expect
> noticable performance difference on a same server, shall I use Python /
> Django than if I had C Sharp Asp.net ?
> I don't want to invest lots of time and efforts only to discover in the
> end that the site is slow.
> You that have real world experiences with running sites, what are your
> conclusions ?
>

Instagram is a Django site. Disqus is a Django site. Many of the Mozilla
properties are Django sites. I guarantee that these sites serve more
traffic than your site will *ever* serve.

Don't get me wrong - these sites have all had to pay careful attention to
the design of their systems, and in many cases have made extensive
modifications to "stock" Django to support high performance. However -
again - they also serve *much* more traffic than your site will *ever*
serve.

C#/ASP.net isn't magical performance sauce. Django and/or the Python GIL
isn't a magical performance drain. The choices you make in database schema
design, caching strategies, query profiling and algorithm choices will
affect your site performance *long* before the limitations of Python or
Django start to become the limiting factor.

My advice to you - as long as your candidate frameworks meet basic
performance requirements, and there's evidence that they can scale to
larger sites (ASP.net, Django, and Ruby on Rails all easily meet these
criteria), don't worry about performance. Worry about the language you like
to use, the speed of development, the community that exists around the
tools, and so on.

Yours,
Russ Magee %-)

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

Re: Django GUI Frameworks?

[Russell Keith-Magee]

Hi Thomas,

On Wed, Feb 25, 2015 at 4:29 AM, ThomasTheDjangoFan <
stefan.eichholz.ber...@googlemail.com> wrote:

> Hi ya,
>
> I wonder if Django has any gui-frameworks which give common solutions for
> handling frontend data, p.e. in combination with Twitter Bootstrap?
> Some time ago I had a look at the YII PHP Framework and they have a great
> solution called Yiibooster (check it out at
> http://yiibooster.clevertech.biz/jsonGridView).
>
> Yiibooster offers a lot of widgets - all in one framework.
> Is there anything like this for django?
>

Your question highlights that you've missed an important point.

Django is fundamentally a server-side framework. That means it mostly
handles database requests, HTTP requests, cookies, and so on. At the end of
the day, it's a big function for turning  "http://example.com/mypage"; into
"...".

What you put *inside* the  is entirely up to you. You want to use
bootstrap? Use bootstrap. You want to use Zurb Foundation? Use Zurb
Foundation. You want to use JQueryUI? Use JQueryUI? Want to use all three?
Use all three.

Django doesn't care *what* you render to the client - it provides a
template language to make it easy to render whatever you want.

So - at it's core, your question doesn't make sense. No, Django doesn't
provide support for handling frontend data - because you can use whatever
frontend solution you want.

That said, there are some ways that third party developers have been able
to make it *easier* to use frontend tools with Django, by doing things like
providing template tags to render frontend widgets, and providing Django
REST framework configurations to support specific AJAX callback formats.
These usually come in the form of third party libraries, which you can
generally find by Googling for "Django ". I
don't have any specific recommendations for good ones, but Django Packages
[1] might give you some guidance.

[1] https://www.djangopackages.com

Yours
Russ Magee %-)

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

Re: Design question: Is it really a good idea for models having “side effects”?

[Russell Keith-Magee]

On Fri, Feb 20, 2015 at 4:23 PM, Gergely Polonkai 
wrote:

> Hello,
>
> I’m currently implementing a finite state machine in my application using
> Django FSM[1]. In the Usage section of the README the author said that
> “This function may contain side-effects, like updating caches, notifying
> users, etc.”
>
> Opposing this statement, the Symfony PHP framework’s authors say that
> models should never have such side effects.
>
> Thus, I was wondering what is the case with Django in this topic. Should I
> really do such things, like notifying users, in the model’s code?
>

Separation of concerns isn't a Django thing or a Symfony thing - it's a
good software engineering thing.

I can't speak for the creators of Django FSM, but if I was to try an
interpret that statement, I'd say what they were trying to say is "this is
a place from which you can trigger other side effects", not "this is the
best place to put side effect logic".

It's a bit difficult to discuss without a concrete example, but I'd suggest
that the internal logic of your FSM isn't the best place to put complex
logic that touches external services (unless, of course, your FSM is
directly tied to managing that service). However, it *would* be appropriate
for your FSM to take the trigger of a state change, and use that as a
trigger for other system changes.

Put another way -  look at the process for testing your FSM. Will you be
able to test your FSM without a fully functional cache, notification
system, etc? If you're not able to configure your FSM in such a way that a
mock of your notification service can be passed in as a configuration
parameter, then you've probably coupled your FSM and your side effect logic
too closely. However, if you *can* drop in a testing mock as a
configuration item, you've captured the *type* of side effect that you
expect to occur, without tying it to a specific implementation.

Yours,
Russ Magee %-)

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

Re: cache.set(key, timeout=0)

[Russell Keith-Magee]

Hi Thomas,

You are correct - if you set timeout=0, the cached value immediately expire
(effectively "don't cache").

This appears to be an oversight of the documentation; the section you
reference includes a discussion of the None value, but not the 0 value - a
clarification would definitely be worthwhile.

If you open this as a ticket, we can make sure your suggestion isn't
forgotten. It would also be a very easy contribution to make - the patch
would be a very simple one

Yours
Russ Magee %-)

On Tue, Feb 10, 2015 at 4:51 PM, Thomas Güttler  wrote:

> I want the cache timeout to be configurable:
>
>  - N --> number of seconds
>  - None --> cache for every
>  - 0 --> do not cache at all.
>
> I am not sure if timeout=0 really does what I want.
>
> I could not find it explicitly in the docs: https://docs.djangoproject.
> com/en/1.7/topics/cache/#basic-usage
>
> I don't want to put a lot of "if default_cache_timeout==0: " into my
> code.
>
> It would be nice if django would support this. This would make my code
> simpler.
>
> Does cache.set(key, timeout=0) do no caching at all?
>
> If yes, shouldn't this be stated in the docs explicitly?
>
> Regards,
>   Thomas Güttler
>
> --
> Thomas Güttler
> http://thomas-guettler.de/
>
> --
> 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/54D9C6A3.9030506%40tbz-pariv.de.
> 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/CAJxq848%2B1yeLrh76QDJmgZPNet_s4-G%3DLe9OAM%2BxYnh%3D%2BAjZFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: App for storing ChangeLogs in database

[Russell Keith-Magee]

On Fri, Feb 6, 2015 at 8:24 PM, Thomas Güttler  wrote:

> Hi,
>
> we want to make the changes in our applications better visible for our
> customers.
>
> We use several git repos:
>
>  - foo_customer: Here settings.py lives. It is quite small.
>
>  - foo_core: Central part of our application. The same code gets used for
> several customers.
>
>  - foo_plugin_bar: Just an example. There are several optional plugins.
>
> Here is my current road map:
>
> A nice interface for the customer implies: The changes need to be stored in
> the database. This makes it easy to sort and filter the changes.
>
> The origins of the changes are the git repos. I don't want to show
> the customer our commit messages. I want a manual step from
> commits to ChangeLog. But that's ok. This could be optimized later.
>
> Use Case: A developer merged a feature branch into foo_core.
> He needs to create a ChangeLog. The ChangeLog gets stored
> into the git repo, but on the next deploy some tool reads
> the new changes and puts them into the database.
>
> ChangeLogs need to be tag-able: You can apply tags like
> "performance-improvement"
> "new-feature" "bug-fix".
>
>
> I searched the web, but could not find something like this.
>
> Before I start to code, I want to get some feedback:
>
> What do you think?
>

To me - it sounds like something pretty closely tied to your own
development process, branching policies, and customer relationships. I have
no difficulty seeing how this could be implemented as a Django app - and a
fairly trivial one at that - your average change log is really not much
more than:

class Change(Model):
message = TextField()
created = DateTimeField()
change_type = IntegerField(choices=CHANGE_TYPES)

How do you handle your ChangeLogs.
>

Through a process that is completely unrelated to the commit process.

For me, minimising the number of customer communications is key. I have
difficulty getting users to read and comprehend the notifications I *do*
send them - sending them complete change logs would be overkill, and would
result in important messages (like YOU NEED TO UPDATE YOUR ACCOUNT SETTINGS
OR THINGS WILL STOP WORKING) being ignored. As it is, these messages are
often ignored, and I need to follow up with individual users.

My audience would gain nothing from a fine grained commit log telling them
about every bug fix or performance improvement. They just want the system
to work. If it doesn't work, they email me, and they'd like to know when it
is fixed. To that end, I might not even send out a notification for a new
*feature*, unless that feature is something that has been requested by
them, or it will impact on the way they're using the system.

Lets be clear, though - I'm not saying your approach is *wrong*. I'm just
saying it wouldn't work *for me*. You know your own users/customers better
than I do.

Yours,
Russ Magee %-)

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

Re: Pillow on QPython3

[Russell Keith-Magee]

Hi Adewale,

Installing Pillow is always a bit of a struggle, because it involves native
code - the pieces of pillow that do the actual image processing rely on
system libraries for handling JGEG, PNG etc. If the makers of QPython
haven't included Pillow (or PIL) in their build, you're going to be
fighting an uphill battle to get it working. If you're not comfortable
dealing with Autoconf files and C compilers, you're probably not going to
get it working.

That said - Django should run without installing Pillow, as long as you
don't try to use an ImageField. Skip over whatever step is telling you to
install Pillow, and see what happens when you work through the tutorial.

Yours
Russ Magee %-)



On Tue, Feb 3, 2015 at 9:36 PM, ADEWALE ADISA 
wrote:

> Hi guys, am try to setup django tutorial with QPython3 on android device.
> But the problem is am unable to install Pillow on the Qpython3. Its just
> giving me various error. I try Qpython forum but with no avail.
>
> --
> 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/CAMGzuy8-9uFqB%3D2otM2pbZ25iVSn4k6MeU7T5S9EBRNx7zLwXA%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 
https://groups.google.com/d/msgid/django-users/CAJxq84-YtsTEkyoph-r5o5L9tEBFVAXrMQnRc%3DY5nHqR7uLLqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Kickstarter: Django opensource improved import-export package

[Russell Keith-Magee]

Hi,

Best of luck with your Kickstarter!

However, I'd like to advise that your usage of the Django logo my be
bordering on a violation of the Django trademark license:

https://www.djangoproject.com/trademarks/

It isn't clear if "will code Django for food" is a product name, service
mark, or tagline. If it's a commercial mark of any kind, you're almost
certainly violating the trademark license. By using the logo and requesting
money, you're also obliged to make a statement about the proportion of
funds that will be given back to the DSF.

If you've got any questions about the terms of the license, please get in
touch and I'm happy to clarify.

Yours,
Russ Magee %-)

On Mon, Feb 2, 2015 at 3:50 AM, mtr group  wrote:

> Hi guys! We launched a project on a kickstarter hoping for your support
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> https://www.kickstarter.com/projects/1625615835/django-opensource-improved-import-export-package
>
> --
> 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/cd204151-2f8f-485a-a004-2a099d4d5e0b%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/CAJxq84_eW4eGu%3DSe0%2Be9zknGyeK%2BXtx3%2BpjzSnQ8BXcFzQeqRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Restrict downloading files in Django?

[Russell Keith-Magee]

On Sun, Feb 1, 2015 at 1:33 AM, Javier Guerra Giraldez 
wrote:

> On Sat, Jan 31, 2015 at 11:52 AM, Robert Rössler 
> wrote:
> > what is the best way to restrict downloading files only to authorized
> users?
>
> it's not hard to do if you manage the file downloading with a view.
>
> of course, file serving within Django is very inefficient, your
> webserver (Apache, nginx, etc.) is far more efficient at this.
>
> so, the solution is to write a view that looks like it's serving the
> file (after checking for authorization), but instead of actually
> serving, delegates the job to the webserver.  check X-Accel-Redirect
> (nginx) or X-Sendfile (apache)
>

The X-Sendfile (or analog) approach is the right way to go - there are even
Django apps that can help manage this process. See:

http://www.paulpepper.com/blog/2014/02/django-x-sendfile-and-apache/

For a recent blog talking walking through the process.

Yours,
Russ Magee %-)

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

Re: using Django on an existing mysql schema

[Russell Keith-Magee]

On Fri, Jan 30, 2015 at 10:47 PM, William Muriithi <
william.murii...@gmail.com> wrote:

> ‎Hello,
>
> I am new to Django and planning to use it for a project I have in mind. I
> am strong in mysql, but not too good in developing. In fact, the secondary
> purpose of this project is to improve my python development skills.
>
> With such a background, I went about doing my data modeling and then set
> up views on top to de normalize the underlying schema and pushing most of
> the business logic in mysql. I want to use Django mainly to insert and
> display, which increases the chance of success with few bugs.
>
> Problem is, with Django, it seems things are done the other way around.
> After playing with it, I noticed it changes the keys from unsigned to
> signed, something I feal is bad from database point of view. It converted
> enum to char, which to me is less appealing. In short, I don't like the
> change its introducing. ‎
>
> My question is, can one use Django with an existing database without
> getting in trouble with the framework? I believe this has to be possible
> somehow as most companies work from data backwards. Would appreciate a good
> advice on how you guys and girls went‎ about using Django from existing
> schema. Or a Django book that take that perspective. The once I have read
> advice me to leave database work to orm.
>

Yes, you can. Django's ORM is there to make your life easier, but there's
no requirement that you use it to create your tables, or even to execute
queries. There's an inspectdb management command to help build wrapper
models for your database; but if you want, you can avoid the ORM entirely,
and use raw database cursors to talk directly to the database.

Of course, if you do this, you're going to miss out on at least some of the
power of Django.

For example, Django has a forms library, which is quite powerful. You can
use it without using Django's ORM. However, if you *are* using Django's
ORM, you can use ModelForms, which is a way to automatically generate a
form for a model.

You're also going to miss out on the community of apps that are out there
to help you get functionality running easily. For example, if you don't
have Django ORM models, then Django's admin interface wont work. A lot of
the power of Django is that it has a good "meta" understanding of the data
in the database; if you take that away, then the functionality that relies
on it obviously wont work.

There's nothing inherently wrong with this - you can code everything
yourself if you want and treat Django as little more than a request routing
library. The only problems you're going to experience are related to the
fact that documentation out there will generally assume that you're using
Django models, not rolling your own. My only concern is that this might
leave you with an odd perception of the capabilities of Django.

Yours,
Russ Magee %-)

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

Re: using Django on an existing mysql schema

[Russell Keith-Magee]

On Sat, Jan 31, 2015 at 3:14 AM, Tobias Dacoir  wrote:

> I'm certainly no Django expert, but I'm not sure if you can use the orm
> and an already existing database.
>

Yes, you absolutely can. There's even a management command (inspectdb) to
help write the wrapper models, and a Meta flag (managed=False) to make sure
the migration tools won't touch those models.


> However the documentation states that you can write all queries yourself,
> essentially not using the orm. However if you do that, I'm wondering why
> you want to use Django at all?
>

Because Django has a lot more than just an ORM. There's a forms layer,
authentication tools, and lots more.


> And pushing business logic into the database sounds like bad design to me
> (model and controller should be decoupled in MVC like patterns).
>

It depends what logic you're talking about, and what other tools will be
using the same database. "MVC" separation like you are describing assumes
that the Controller is shared; if you have to re-implement the controller
in two languages, then there's a very strong argument to push some of the
controller's functionality into the database.

Yours,
Russ Magee %-)

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

Re: Two user model problem

[Russell Keith-Magee]

On Thu, Jan 29, 2015 at 1:39 AM, 詹上潁  wrote:

> Before I use the design as I mention above, I had thought of using two
> type of profile.
> Using two profile model in a project, I need to implement two login page
> for each type of user, and I also need to check which of user is logging in.
> I need to implement a custom login_required decorator to protect views,
> maybe called staff_required and normal_user_required.
>

No matter what approach you use, you're going to need to do this.


> I need to specify two LOGIN_URL for both type of users.
>

Not necessarily - after all, logging in a *user* doesn't require you to
know whether someone is an admin or not. It's only where you redirect after
they log in that might be affected. So, you could have a single LOGIN_URL;
LOGIN_REDIRECT_URL could then be a page that does another redirection,
based on whether the user is an admin or regular user.


> What is the good way to tell which type of user is logging in? Add a type
> field to User model?
>

You *could* add a user-type field to the base user model; alternatively,
you can just query for the existence of an admin profile. Assuming you use
a 1-1 field for the profile, this would mean code something like::

user = User.objects.get(username=username)
try:
admin_profile = user.admin_profile
# user is an admin user
except AdminProfile.DoesNotExist:
# user is not an admin user.

This also means you can do things like:

 * have an expiry date on admin privileges - just add extra checks for
user.admin_profile once you've got it.

 * have *both* an admin profile and a user profile (for admins that also
use the system as users)

Is it good to put staff user and regular user's username and password in
> same database and same table?
>

I can't see any reason why it would be a bad thing.

P.S I am a newbie. I ask many question, because I want to know what is the
> best practice for production level project. What are pros and cons of these
> different implementation.
>

Understood - you've been asking very reasonable and detailed questions, so
I'm happy to answer them :-)

Yours,
Russ Magee %-)

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

Re: Two user model problem

[Russell Keith-Magee]

On Wed, Jan 28, 2015 at 9:32 PM, Andreas Kuhne 
wrote:

> 2015-01-28 13:26 GMT+01:00 Russell Keith-Magee :
>
>>
>> On Wed, Jan 28, 2015 at 3:00 PM, 詹上潁  wrote:
>>
>>> My project need an admin for staff and a normal website for normal user.
>>> Staff can only login to staffsite and normal user can only login to
>>> website. Staff will login to admin to do some management. They can
>>> view normal user list and detail and create or delete normal user
>>> admin. The two type of user is very different, so I want to write a model
>>> for each of them, instead of using is_staff flag. But in a project, I can
>>> only have a USER_AUTH_MODEL. Is there a good way to implement these
>>> requirements?
>>>
>>> Since a project can only have a USER_AUTH_MODEL, I separate the two type
>>> of user in two project (staffsite and website).
>>> My currently design and implementation is as follow:
>>>
>>> I wrote a standalone django app called member, and implement Member model
>>>
>>> class Member(AbstractBaseUser):
>>> #member related fields
>>>
>>> then I create two project “staffsite" and “website". “staffsite" is for
>>> internal use, “website" is open for normal user. “staffsite" just use the
>>> django built in auth.User. Member model in “staffsite" is just a normal
>>> model. “website" use Member model as USER_AUTH_MODEL.
>>> I have two database, one for “staffsite" and one for “website". Since
>>> “staffsite" need to access Member’s data, so I implement a db router for
>>> “staffsite". Whenever I need to access Member’s data in
>>> “staffsite", router will route me to the correct db (You can say that I
>>> use db to link “staffsite” and “website” together.)
>>>   member app need to install in both “staffsite" and “website", so I
>>> will have two copy of member app. This is not good for
>>> maintenance. Whenever I change the code in member app, I need to copy and
>>> paste to another one. I extract member app and create a standalone app, and
>>> after that I can use pip install -e  to install member app for
>>> both project and I only have to keep one copy of code.
>>>
>>> This design is work, but I want to know whether there is a better way to
>>> meet the requirements.
>>>
>>
>> Yes, this approach will work. It might be the best approach if you really
>> do have 2 completely different sites (even different URLs) that share a
>> little bit of data.
>>
>> However, if you've got a single site that just has 2 different types of
>> users, an approach that might be easier to manage is write a common "user"
>> model, and then have different profiles for Admin and Normal users.
>>
>> This captures the idea that a User isn't something that contains
>> specialised information - it's purely a container to hold a username and
>> password. Once a user has logged in, if there is specialist information
>> needed, then you put that information onto a profile model that has a
>> foreign key to the user model.
>>
>> Think of it this way - regardless of whether someone is an staff member
>> or a normal user, they're still a person. The User model should be
>> capturing the fact that they're a person; then, you build other data models
>> to store information about their other roles.
>>
>> The added advantage of this approach is that a single User can be both an
>> Staff member and a Regular user, as needed - because they have a single
>> User, but 2 different profiles.
>>
>> I hope this helps.
>>
>> Yours
>> Russ Magee %-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/CAJxq848vK8wqX6viT2mdkz4chcP3MfjOq7mceH%2Bss_9S3dWmXA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-users/CAJxq848vK8wqX6viT2mdkz4chcP3MfjOq7mceH%2Bss_9S3dWmXA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> I&#

Re: Two user model problem

[Russell Keith-Magee]

On Wed, Jan 28, 2015 at 3:00 PM, 詹上潁  wrote:

> My project need an admin for staff and a normal website for normal user.
> Staff can only login to staffsite and normal user can only login to
> website. Staff will login to admin to do some management. They can
> view normal user list and detail and create or delete normal user
> admin. The two type of user is very different, so I want to write a model
> for each of them, instead of using is_staff flag. But in a project, I can
> only have a USER_AUTH_MODEL. Is there a good way to implement these
> requirements?
>
> Since a project can only have a USER_AUTH_MODEL, I separate the two type
> of user in two project (staffsite and website).
> My currently design and implementation is as follow:
>
> I wrote a standalone django app called member, and implement Member model
>
> class Member(AbstractBaseUser):
> #member related fields
>
> then I create two project “staffsite" and “website". “staffsite" is for
> internal use, “website" is open for normal user. “staffsite" just use the
> django built in auth.User. Member model in “staffsite" is just a normal
> model. “website" use Member model as USER_AUTH_MODEL.
> I have two database, one for “staffsite" and one for “website". Since
> “staffsite" need to access Member’s data, so I implement a db router for
> “staffsite". Whenever I need to access Member’s data in
> “staffsite", router will route me to the correct db (You can say that I
> use db to link “staffsite” and “website” together.)
>   member app need to install in both “staffsite" and “website", so I will
> have two copy of member app. This is not good for maintenance. Whenever I
> change the code in member app, I need to copy and paste to another one. I
> extract member app and create a standalone app, and after that I can use
> pip install -e  to install member app for both project and I only have to
> keep one copy of code.
>
> This design is work, but I want to know whether there is a better way to
> meet the requirements.
>

Yes, this approach will work. It might be the best approach if you really
do have 2 completely different sites (even different URLs) that share a
little bit of data.

However, if you've got a single site that just has 2 different types of
users, an approach that might be easier to manage is write a common "user"
model, and then have different profiles for Admin and Normal users.

This captures the idea that a User isn't something that contains
specialised information - it's purely a container to hold a username and
password. Once a user has logged in, if there is specialist information
needed, then you put that information onto a profile model that has a
foreign key to the user model.

Think of it this way - regardless of whether someone is an staff member or
a normal user, they're still a person. The User model should be capturing
the fact that they're a person; then, you build other data models to store
information about their other roles.

The added advantage of this approach is that a single User can be both an
Staff member and a Regular user, as needed - because they have a single
User, but 2 different profiles.

I hope this helps.

Yours
Russ Magee %-)

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

Re: Looking for a way to broadcast live video streams. Is it possible with Django ?

[Russell Keith-Magee]

Hi Jeremy,

What you're trying to tackle here is fairly complex - and for the most
part, won't have anything to do with Django. The capability of capturing
webcam video and sending it will be almost entirely "client side" - which
means that the logic will reside in the browser, and will be implemented in
Javascript.

The only involvement Django will have will be:
1) Sending the initial content to the user
2) Receiving video content, if it's going to be archived.

If you're looking to do Hangout-like stuff, you're going to be using the
WebRTC extensions that are available in *some* browsers - the best
resources I can point you at are:

http://www.webrtc.org
http://simplewebrtc.com

But even then - the specification isn't widespread. Safari, for example,
doesn't support WebRTC, and neither does IE. That doesn't mean you can't do
hangout in Safari or IE - clearly you can - but it means the interface
isn't going to be easy, either.

Yours,
Russ Magee %-)


On Tue, Jan 27, 2015 at 10:05 PM, Jeremy Hermelin <
contact.herme...@gmail.com> wrote:

> Hi everybody,
>
> I'm quite new in Django community. I've just learn the basics of the
> framework, and now that I know how to create a "blog-style" website, I'm
> wondering how to integrate video streams in my project. Do you have some
> advices about that ? Any existing app ?
>
> What I am looking for precisely :
> - Capturing video stream from a client's webcam (Maybe the easier will be
> using a script)
> - Sending the stream to the server and then to hundreds of clients
> connected to this session.
>
> In fact, it's really close to Google Hangout.
>
> As I said, I'm new in Django, and also in Python, then I'm sorry if the
> answer is obvious. I've made some research on djangopackages but haven't
> find anything.
>
>
> Have an awesome and fantastic day,
>
> Jeremy
>
> By the way : Wooohhh Django is so easy and powerful at the same time !
>
> --
> 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/cb8c96bf-854f-4ed5-a803-6cd943c767df%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/CAJxq848K_20u7%3DNTAV1TseZE6GHp-HQEhg%3D4WrBABtm5hauQrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Downloading thumbnails and replacing them with full images

[Russell Keith-Magee]

On Sat, Jan 24, 2015 at 12:20 AM, Larry Martell 
wrote:

> I have a django app that downloads 100's of images. To increase the
> performance, I want to change it so that it downloads thumbnails, and
> when the user clicks on one then download the full image.
>
> I'm sure I can come up with something on my own (send an ajax request
> on click, etc.) but I was wondering if anyone has already done
> something like this and knew of any packages or can give any hints or
> advice.
>

My suggestion - look into easy-thumbnails:

http://easy-thumbnails.readthedocs.org/en/latest/index.html

It's an augmentation of Django's ImageField that allows you to store a
"single" image in your model, but also specify policies for how thumbnails
of any image will be generated (in multiple sizes, if needed). The field
will then automatically generate those thumbnails (either on upload, on
demand on download, or in a background process, depending on how you
configure it), and provide an easy way to find the media URL for each
thumbnail (as well as the original).

Yours,
Russ Magee %-)

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

Re: Accessing Django test client in setUpClass

[Russell Keith-Magee]

Hi Nicole,

(I've added this answer to SO as well)

Short answer is no - but that's not the end of the story.

self.client is a convenience that is configured as part of the "pre-test"
sequence. This means it is configured on a per-test basis; so you can use
it in setUp(), but not setUpClass().

However, there's nothing especially magical about self.client - it's just
an instance of django.test.Client that Django sets up for you because it's
something that is very useful to have around. You can set up your own
client if you want - you just have to instantiate an instance of Client:

from django.test import Client
...
self.myclient = Client()

and then use self.myclient as you would self.client. This can be very
useful if you need to check "two user" behaviour - for example, checking
that if an admin approves an article, a user can then see it. You create
two clients, log them in with separate accounts, and then GET the same
article URL with each client. In your case, you could create a client
purely for class setup activities.

The only caveat on using django.test.Client in setUpClass() relate to
transactional side effects. setUpClass() doesn't fall inside the
transaction protection of a test case, so anything you do in setUpClass()
will be "permanent" on the test database. You'll need to manually roll back
or undo any database changes that setUpClass makes, or you'll get
cross-testcase side effects.

If you're using Django 1.8, you can use setUpTestData() instead - in this
case, anything the client does *would* be protected by a transaction.

Yours,
Russ Magee %-)


On Thu, Jan 22, 2015 at 5:08 PM, Nicole Harris  wrote:

> I just posted this on Stack Overflow and then realised I might have more
> luck here.
>
> Basically, I'd like to know if I can access self.client inside
> setUpClass(cls) when setting up a Django test:
>
> http://stackoverflow.com/questions/28084683/accessing-django-test-client-in-setupclass
>
> If anybody has any insight on this, I'd really appreciate it :)
>
>  --
> 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/fb4e3cd7-a70a-4a7c-b61f-f6ef73d7e226%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/CAJxq849Ep%2BDgmneQdbxvjDsZ%2BN50vCdy7yMa6xfi13y1FbQFMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Communication between listboxes in form

[Russell Keith-Magee]

On Thu, Jan 22, 2015 at 4:17 PM, joulumaa  wrote:

> Hi, beginner question.
>
> I need to have two listboxes A and B on web page, When user selects one
> item from A it should add it in B.
>
> If I understand right, form A should somehow save change to database and
> wake up form B to update its query.
>
> Where should I start in documentation?
>
>
Hi,

This isn't really a Django question, per se - it's got more to do with
JavaScript on the client side.

The only Django component will be a form that contains 2 ManyToManyFields.
However, that just provides the way to render the initial A and B lists,
and commit them when they are saved.

The process of moving an item from one list to another will require
JavaScript. Django doesn't provide anything to do this out of the box.
There are plenty of toolkits to do this; it's up to you to investigate your
preferred option. However, jQuery is one place to start.

If you want to do this in a truly dynamic fashion - i.e., saving each
individual list change as it happens, rather than "make a bunch of changes,
and commit", you're in a whole other territory; you'll need to investigate
AJAX and APIs.

Yours
Russ Magee %-)

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

Re: Question for Django Core Team?

[Russell Keith-Magee]

On Sun, Jan 18, 2015 at 8:28 PM, Petar Pilipovic  wrote:

> Hello there this is maybea of topic but I wont to ask Django Core Team,
> did they now someone who is practising Django in Belgrade-Serbia, or
> Zagreb-Croatia, I now there is a strong Slovenia team there, but I was
> wondering about this area around Bosnia where I live in.
> I am asking because I was inspired by this post here
> http://blog.djangogirls.org/post/108268319658/django-girls-core-team-grows,
> and mine chat whit Daniel Roy Greenfel @pydanny
>  over Twitter
> https://twitter.com/Coopsess/status/556665409693163520.
> So do you now eny one?
>

Hi Petar,

This isn't really a question for the Django core team, because Django Girls
isn't an official part of the Django project. We're excited to see the
great work that they're doing, and members of the core team help out with
Django Girls events whenever we get a chance - but they're an independent
organisation.

There was an event in Ljubljana on 18 October, but the website doesn't list
any upcoming events in Serbia or Croatia.

http://djangogirls.org/events

If you'd like to organize an event, they're always looking for volunteers -
register your interest here:

http://djangogirls.org/organize/

and I'm sure they'll be in contact soon.

Yours,
Russ Magee %-)

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

Re: Instructions from Django to run under Python don't work.

[Russell Keith-Magee]

On Sun, Jan 18, 2015 at 10:23 AM, Lisa Jennings 
wrote:

> I have been trying for two days to install django with Python 3.4
> operating in windows 7.  Everything I try according to your instructions,
> fails. The command "import django" seems to work but the command "print
> (django.get_version()) does not. I am trting to get this to work so I can
> install ESMPY a version of ESMF. Any help will be appreciated.
> Megan
>

Hi Megan,

It would be helpful to know what "doesn't work" means. Do you get an error
message? If so, what is it? If not, do you get *absolutely nothing*, or do
you get something, but just not what you expect to get? Does the command
return you to the command prompt?

Without more details about what you're seeing, it's almost impossible to
guess the source of the problem you're having.

Yours
Russ Magee %-)

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

Re: do migrations (Django 1.7+) handle production data?

[Russell Keith-Magee]

On Wed, Jan 14, 2015 at 3:03 PM, Abraham Varricatt <
abraham.varric...@googlemail.com> wrote:

> Hello everyone,
>
> One of the biggest features introduced in Django 1.7 are migrations. They
> can broadly be classified into 2 types -
> * schema migrations
> * data migrations
>
> Schema migrations deal with changes to the database schema. eg - changing
> max_digits of a DecimalField.
> Data migrations revolve around the actual data in your database and are
> not automatically taken care of.
>
> My question is;
>
> Why is there so much praise for the Django (1.7) migrations feature if it
> can't handle data? Yes, I can understand the convenience of schema
> migrations, but without it being accompanied by data migrations, what's the
> point? (I'm assuming that this is something run on a production
> environment. For test/development environments, the data can arguably be
> worthless)
>

What gave you the impression that Django's migrations doesn't handle data?
There's a section in the Migration topic guide in Django's documentation
entitled "Data Migrations":

https://docs.djangoproject.com/en/1.7/topics/migrations/#data-migrations

Yours,
Russ Magee %-)

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

Re: AWS FOR STEEL PLATE TO SUS316L

[Russell Keith-Magee]

Hi MajiD,

Are you sure you've got the right mailing list?

It sounds like you're talking about arc welding - this is a mailing list
discussing a computer software framework called Django.

If your question *is* about Django - you're going to need to explain your
acronyms, because AWS is the only one I recognise.

Yours,
Russ Magee %-)

On Sat, Dec 27, 2014 at 10:38 AM, M.suffian aris 
wrote:
>
> Dear Sir,
>
> I'm new in this group,
>
> can you advise to me which one  AWS / SWPS for STEEL PLATE EH36 combine to
> SUS316L  ( FCAW ).
>
> your full co-operation very appreciated,
>
> regard,
> MajiD
>
> --
> 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/e0a747fe-64f1-4e83-89a1-0b3c3660932c%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/CAJxq849wxwtfquUxcKt6%2B4_w%3DZr7Qc6fc_oDAeKScaPxM19oqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: potential bug with defer() & only()

[Russell Keith-Magee]

Hi Will,

On Tue, Dec 23, 2014 at 3:56 PM, William Earp  wrote:
>
> Hi all,
>
> I'm writing some tests #18586) for defer() and only() and there appears to
> be a bug when it comes to chaining these two in a single query.
>
> If you look at the docs (
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.only),
> it says this:
>
> # Final result is that everything except "headline" is 
> deferred.Entry.objects.only("headline", "body").defer("body")
> # Final result loads headline and body immediately (only() replaces any# 
> existing set of fields).
>
> Entry.objects.defer("body").only("headline", "body")
>
> However, when I test the last example "body" is still deferred after only() 
> has been applied to it. In a situation where there are only these two fields 
> in a model there should be no deferred field.
>
> Is there any reason for this or does this need reporting as a bug. If so, 
> what's the procedure for this?
>
> Well, either the code is wrong or the documentation is wrong, so
*something* needs to be changed. The documentation describes what I
understood to be Django's behavior, so it if isn't working like that, then
it sounds like you've found a bug.

To report it, visit

https://code.djangoproject.com

and on the top left, there's a "New ticket" button. (You may need to log in
first - either with your Github account, or by creating a Django Project
account).

Fill in the details (pretty much what you've done here, but also provide
Django + Python version numbers, and the database you're testing with), and
someone else will try to replicate the problem you describe.

Yours
Russ Magee %-)

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

Re: Poll Tutorial (for Django 1.7) Files Available?

[Russell Keith-Magee]

Hi Ken,

No - the full tutorial code isn't available anywhere (at least, not in an
official capacity). If you need help debugging a problem, let us know what
error you're getting, and we might be able to help you; if you're looking
for some immediate feedback, try the #django IRC channel. There's usually
someone there who will be willing to help someone work through the tutorial.

Yours,
Russ Magee %-)

On Tue, Dec 23, 2014 at 7:06 AM, Ken Wayne  wrote:
>
> I'm trying to work through the Poll Tutorial and I've run into some
> problems.  I'd like to compare the code I've written to a working file.  Is
> there any place to download the entire working 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/26f1c16c-865c-43a6-910e-5dd90beb22bb%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/CAJxq849M2t8LvifSoub1bkc5Bjh0KS94DOWagoCVzYMDyD%3DK0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Raw access to cache table

[Russell Keith-Magee]

On Sun, Dec 21, 2014 at 12:55 PM, Collin Anderson 
wrote:
>
> Hi Erik,
>
> If you want a nicer interface, I just ran manage.py inspecdb on one of my
> databases and got this for the cache table. Not sure why django still does
> it by hand.
>

Gather `round, children, and let Grandpa fill you in on the details... :-)

Although it isn't huge, Django's ORM does have an overhead. If you're
looking for the general capability to query rows on a database, this
overhead is a reasonable price to pay - you have a little overhead, but
it's a lot easier to express complex queries. However, in the case of a
cache table, you need to issue exactly 2 queries:

1) Get me the object with key X.

2) Set the value of key X.

These two queries are trivial to write -- so trivial in fact, that they
don't even need to rewritten as they move across database backends. They're
as "vanilla" as a query can get in SQL.

So - this becomes a case study in when *not* to use the ORM. We know the 2
queries that need to be issued. That SQL isn't hard to write or maintain.
And using the ORM would impose a non-trivial runtime overhead - and by
definition, a cache backend is supposed to be as efficient as possible. Raw
SQL is the "right" answer here.

(well not using a database backed cache backend is the *really* right
answer, but I'll let that slide for the moment...)

If you *do* want to do complex queries on the database cache table, the
approach suggested by Collin is as good an approach as any. A managed table
will give you ORM operations over an arbitrary table - include Django's own
internal tables.

That said, I'll also concur that the database cache backend is the wrong
answer here. If you're writing a cron script, the approach I've always used
is PIDfile based lock:

http://unix.stackexchange.com/questions/12815/what-are-pid-and-lock-files-for

Yours,
Russ Magee %-)

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

Re: Loving the new site / Performance and Optimization

[Russell Keith-Magee]

Hi JJ,

For archival purposes, I've just deleted your post from the Django Users
archive.

Pete and the team at Lincoln Loop are long standing, highly respected
members of the Django community, and you've just done them a huge
disservice.

The very first page in the "High performance Django" book contains the text:

"""
Sharing your copy to the world on public sites, torrents, etc. is not fair
use. Please don’t do it.
"""

So, *of course* that meant you had full permission to send this
PDF to a mailing list of 22000 people. 

Unfortunately, there's nothing I can do to retrieve the book from the 22000
email boxes to which it has already been delivered - the damage has been
done.

Please don't do this again.

Yours,
Russ Magee %-)

On Thu, Dec 18, 2014 at 2:31 AM, JJ Zolper  wrote:

> My fellow Django developers,
>
> First off I just want to say I'm really happy with the new design of our
> website. I think by modernizing our face we will attract new individuals
> into programming and our beautiful web framework Django. My sense from the
> community is that we are very welcoming to those who are new to learning
> how to build websites, and I think this makes us significantly stronger. I
> know from my own personal growth that the Django community has been pivotal
> in helping me attain my dreams as I am nearing the launch of my first
> website, Athletes United, and so I want to give back by bringing new ideas
> that I think will help others grow in their journey just like those before
> me have helped me grow and prosper.
>
> Secondly, I think that by expanding our documentation on Performance and
> Optimization, we will further strengthen our community and continue to
> make our community more well rounded. As an individual who had to teach
> himself how to code and build websites, my feelings stem from the need I
> see in helping others rapidly and effectively learn how to deploy their
> hard work. To accomplish this I would like to suggest to you all today the
> possibility of refactoring and then potentially including the material and
> guidance within Peter Baumgartner & Lincoln Loop's book High Performance
> Django. For reference their Kickstarter can be found here:
>
> https://www.kickstarter.com/projects/1704706557/high-performance-django
>
> I have also attached a copy that I have as a backer.
>
> Potentially another document with a wealth of information we could factor
> in would be Instagram's engineering blog:
>
>
> http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances
>
> I believe we have a great start as seen here:
>
> https://docs.djangoproject.com/en/1.7/topics/performance/
>
> But I would like to stand up and push for further discussions to be had to
> bring about, in my mind, a much stronger support for the final step in a
> django developer's journey. I certainly understand solutions can be on a
> case by case basis but I think supplementing what we currently provide will
> only benefit us.
>
> I think by banding together we can lessen the load on each individual and
> attain an even more comprehensive home on our beautiful djangoproject.com.
>
> Thank you very much for your time today and I hope to hear from anyone who
> wishes to discuss this further soon.
>
> JJ Zolper
>
> --
> 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/a76a7bf2-45af-4ff6-80c6-2117c9104c73%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/CAJxq848KkOvvwUp00n_dvsWS9COT%3D9izSe8eYAuECL6%2BV2Oziw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Russell Keith-Magee]

On Wed, Dec 17, 2014 at 6:55 AM, Schmitt, Christian <
c.schm...@briefdomain.de> wrote:

> Somehow I hate it. The website is the worst website I've seen since a long
> time.
> The contrast is really aweful.
> The issue Tracker got unusable due to the colors that aren't focused on
> readability.
>
> Overall it looks like a mess, just to have a new design.
>
> Doesn't look like a designer or a graphic guy had his hands on that.
> I can't realized why some should replace a good and usable design which
> had some practical usage and also a good readability with the "thing" we
> have now.
>
> Sorry but I will stick to the old docs as for now or use the PDF ones with
> my custom style (since your colors are aweful, too).
>
> Django should focus on a clear design which is helpful for readability and
> not this stupid mess.
>

Thanks for the feedback. Sorry you don't like what we've rolled out.

I can assure you that we *did* engage a "designer or graphic guy" in this
process - several in fact - and they all have significant experience in
designing "usable designs" with "practical usage". The blog post announcing
the launch has the details.

The old design was a classic, but you can't say it didn't have problems -
from a technical perspective, it was almost unusable on mobile devices;
from a functional perspective, it didn't provide a way for us as a project
to highlight community efforts, or draw attention to the DSF or provide
calls to action for people who aren't discovering Django for the first time.

If you've got specific feedback - something we can actually fix or address,
not "I don't like it" - please open a ticket. We've already had some
comments raised about contrast, which the team is looking into. If there's
something else we should know about, let us know and we can address it.

Yours,
Russ Magee %-)

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

Re: ANN: Django website redesign launched

[Russell Keith-Magee]

On Wed, Dec 17, 2014 at 2:38 AM, Jannis Leidel  wrote:

>
> > On 16 Dec 2014, at 17:17, Fred Stluka  wrote:
> >
> > Jannis,
> >
> > Care to summarize what has changed?  At first glance, it looks like
> > mostly the same excellent content and the same sensible
> > organization of info, with the same useful mechanisms like the
> > ability to easily flip between different versions of the docs.
>
> Yeah, the content hasn't changed much, so you can think about this change
> as a new skin to make it look less outdated than before. We're also now
> using techniques like a responsive layout to cater to the current growing
> mobile web audience.
>

As Jannis says, it's mostly visual at the moment - with one exception: the
homepage. The old layout didn't give us space to highlight community
projects, education projects, or the Django Software Foundation. We have
those now, and we have space to put others as they arise in the community.

Yours,
Russ Magee %-)

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

Re: InMemoryUploadedFile object retrieved from request.FILES got closed automatically on django 1.7

[Russell Keith-Magee]

On Tue, Dec 16, 2014 at 4:53 AM, Hong Yi  wrote:

> Hello,
>
> I am new to Django and have implemented two views and their corresponding
> template pages and they are working well in Django 1.6. However, when
> migrating to Django 1.7, I got an error "I/O operation on closed file" when
> getting to the second view function. I found out the root cause for this
> error is that on Django 1.7, InMemoryUploadedFile object retrieved from
> request.FILES got automatically closed at the end of the request by Django.
> I am trying to find a solution to work around this migration issue.
> Specifically, the first view and its template page ask users to browse
> files, and the files can be retrieved from request.FILES and saved to a
> global variable for use by the second view/request. Since the file got
> closed automatically at the end of the first request, when the second view
> tries to operate on this file, that "I/O operation on closed file" error
> results.
>
> This is my first post, and I am trying to get some
> recommendations/suggestions on how to handle this use case to work around
> this new security feature implemented in Django 1.7 (i.e., automatically
> close file at the end of each request). Any help and suggestions are
> greatly appreciated.
>
>
Hi Hong,

In this case, the solution isn't to work around Django - it's to work out
why Django is getting in your way. The cause is a fundamental
misunderstanding about how you should be looking at the web.

Each request on a web site should be completely independent - you can't
rely on shared state between one request and the "next" request. Two
examples for why this is important:

1) The second request might be served by an entirely different server. Once
you get into any sort of non-trivial deployment, you will have more than
one web server to ensure availability; if a file has been uploaded on one
server, it won't be available on the other server unless you're providing
some sort of independent storage.

2) There's no guarantees that a single user will be responsible for two
requests in a row. It's easy to think of a situation where there are two
users using your website at the same time; if your website code makes any
assumptions about request ordering, it makes a big difference whether the
requests are handled as AABB or ABAB. If A and B are normal users, this
might just be an annoying bug; if B is an attacker, then A's data could be
stolen or compromised.

You might claim that your website will never be big enough to require (1),
or have enough users that (2) will be a problem - and that might be true -
but it doesn't change the fact that web frameworks are built on the
assumption that both (1) and (2) are going to happen, and the
infrastructure they put in place will ensure that those two cases don't
cause problems.

So - you shouldn't be using a global variable to store *anything*. (That's
generally good advice for programming anyway, but it's doubly important for
web programming). You also shouldn't be loading data into memory on the
assumption that it will be used in the "next" request. If I were an
attacker, and I found out that you were doing this, I would make a whole
stack of the first requests, and then never make the second request - and
I've just starved your server of memory.

If you need to have a 2 step process where one view selects a file, and the
second view "handles" the file, then what you should be passing around is a
filename, or some other reference that lets you retrieve a file. Then, the
two views should be built so that they are completely independent. View 1
provides a way for a user to select a file. View 2 opens, reads, processes
and closes the file.

Memory usage shouldn't be a concern here. When you open a file, you don't
have to load the whole thing into memory to pass it around. Operating
systems are really good at handling file pointers, which are just an index
into an open file. You don't have to store any more data than the character
you're currently pointing at. Most file formats are developed so that you
don't need to read the *entire* file into memory in one pass - they're
optimised to allow you to read them "on demand".

In short - don't work around this problem; fix the underlying cause of the
problem, and restructure your app.

Hope this has been helpful!

Yours
Russ Magee %-)

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

Re: how to learn django and I don't kill in the attempt,

[Russell Keith-Magee]

On Mon, Dec 15, 2014 at 2:57 PM, Shazwi Suwandi 
wrote:

> +1 to what Jorge mentioned. You can find books online but most of them
> (the ones I found) cover up till Django 1.6 and if you wanna use Django
> 1.7, some things won't apply. For example, things like South is already
> integrated into Django 1.7.
>

Clarifying an important misconception here - South *has not* been
integrated into Django's core.

Django 1.7 includes a migration framework that is similar to, but very
distinct from South.

Yours,
Russ Magee %-)


> All the best :)
>
> On Monday, 15 December 2014 05:49:50 UTC+8, Jorge Luis Callalle Torres
> wrote:
>>
>> how to learn django and I don't kill in the attempt,
>> suggestions, recommendation.
>> Do you know any resource, books videos for learn django from 0 ?
>>
>> 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/2eb6562b-bcc9-4b50-a677-79698c72539b%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/CAJxq84_1e6V%3DTiUSKCPB_TC19Mzykbk9sqxaFbz1dczCfEp6cg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can anyone give me a suggestion or a recommendation as to how I can access the current user's username in the models.py?

[Russell Keith-Magee]

On Mon, Dec 15, 2014 at 9:14 AM, Fred Stluka  wrote:

>  Collin and Russell (and anyone else),
>
> Do you have any opinion on this?
> - https://bitbucket.org/aptivate/django-current-user
>
> It was offered in an earlier post:
> - https://groups.google.com/d/msg/django-users/y7aIbN2_CsA/GtmrSjG1nq8J
>
> as a solution to exactly this problem.
>
> Makes the current user available to the save() method of all
> models.
>
> I read the code and it looks good, but I don't know the details
> of Apache/WSGI/Django/Python multi-threading well enough
> to know if it is thread safe.
>

I haven't deeply audited the code, but based on the approach, I can't think
of any reason it wouldn't be.

A signal is just a mechanism for registering pieces of code to run at known
points in object lifecycle (in this case, just before the internal
mechanics of save() are executed). There's nothing here that should trigger
any multithreaded or cross-process concerns AFAICT. These signals aren't
fired in a separate thread - it's completely linear code execution, via a
code path that has been injected via signal registration.


> Thoughts?
>

IMHO: It's much better than a thread local, but my own engineering taste
says I'd still prefer an explicit call.

I think the current-user package is a fine example of the possibilities
afforded by signals. The problem is that I don't like signals. I've been
burned by signal based frameworks in the past - if you lean on signals as
an engineering approach, it's *really* easy to get into an exponential
signal explosion (i.e., one signal causes 2 signals to be emitted, which
causes the first signal to be emitted again, and so on). Signals are
sometimes unavoidable, but as a matter of taste, I avoid them if at all
possible.

I vastly prefer an explicit argument, for two reasons.

1) It's very clear that it's being used, and where the value for the
argument is coming from. If you use the signal approach, and I'm reading
your code, and I don't know that you're using the CurrentUser signal
approach, then it will be completely opaque to me why and how the current
user is being specified - and there's no immediately obvious source of
places to start digging. I have to audit the entire codebase to find the
signal that is doing the job. This *could* be addressed with good project
on-boarding documentation... but when was the last time you got given a
complete and correct on-boarding document when joining an existing project
:-)

2) The signal approach won't (necessarily) work in all situations - an
explicit argument will. For example, if you want something on a form to be
pre-populated by the current user, there isn't a signal waiting to be used.
Best case, you'll have to define your own "pre-form-render" signal - which
is certainly possible, but it isn't something that is waiting to be used
out of the box, and you'll need to modify the Middleware to honour that
signal as well. This means your middleware will need to have a signal for
every possible way that a current user might be used, and signals aren't
free - a signal with no listeners still has a processing overhead.
Essentially, this means that Current-User *can't* be both high-performance,
*and* applicable to every situation. You either need to customise it for
every project where you use it, or wear a non-trivial overhead for
supporting signals you may never use.

Yours,
Russ Magee %-)

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

Re: Modify a queryset and add computed value to the objects

[Russell Keith-Magee]

Hi Karim,

On Wed, Dec 10, 2014 at 8:07 AM, Karim  wrote:

> Hi everyone! I have a "Services" model and I would like to get a
> QuerySet with all the services filtered based on the distance between
> the logged user and the service.
>
> I have latitude and longitude about the user logged in and I filter
> the services based on the computed distance.
>
> At the moment I build the QuerySet Service.objects.all() and after
> that I exclude the services that I don't need, but I think there is a
> better way to do that.
>
> I was thinking to use a Manager. Quoting the docs:
>
> "Adding extra Manager methods is the preferred way to add
> “table-level” functionality to your models. (For “row-level”
> functionality – i.e., functions that act on a single instance of a
> model object – use Model methods, not custom Manager methods.)"
>
> As a "eternal newbie" I ask you
>
> 1) The distance must be computed based on two parameters "long" and
> "lat". Is that possible to define a manager only for this purpose? Is
> it a good practice?
>

Only if you can perform that calculation "database-side". Since you want to
do a filtering operation, the property you want to filter on must either be
stored on the database, or computable via the database. Essentially, the
manager needs to be no more than a shorthand for a query chain using normal
Django query clauses. You can't use a method on the *model* because that
value will only exist on the Python side of the query, not the database
side.

(A quick caveat - you *could* do it by filtering on the Python side -
essentially, you filter as much as possible on the database, and then
provide a Python-side filter - essentially "[s for s in
Service.objects.all() if s.distance(some_user) < maximum_value]" - but that
puts additional load on your web server. If your list of services is short
to start with, or can be filtered to be relatively short, this might be a
viable option - YMMV)

In some cases, the database filtering can be helped by pre-computing a
filterable value and storing it as a value on the database model, so you
can use a simple Django filter on that value. However, in your case, it's
not just about the lat/long of the object being filtered, but the lat/long
of the user as well.

Managers themselves can't take arguments, so the closest you'll get is a
method *on* the manager that can return a queryset. The fact that the
method is on the Manager is largely irrelevant - that's just a convenience.
You need to be able to construct a query chain, using purely database-side
queries. Putting that method on the manager is really just a convenience to
put the query in an obvious place; being on the manager doesn't give the
query any additional power.

If you're using Django 1.7, you should also look into using custom query
sets *as* managers:

https://docs.djangoproject.com/en/1.7/releases/1.7/#calling-custom-queryset-methods-from-the-manager

This means you'll be able to access your "nearest filter" anywhere in a
query chain. After all - does it really matter if you say:

Services.objects.nearest(some_user).filter(is_fun=True)

or

Services.objects.filter(is_fun=True).nearest(some_user)

(Maybe it does in your particular case, but broadly speaking, it shouldn't).

You may also want to take a look at django.contrib.gis (also known as
GeoDjango):

https://docs.djangoproject.com/en/1.7/ref/contrib/gis/

This toolbox gives you a whole bunch of useful tools for performing
geographic queries, including computing the distance to a point,
determining if a point is inside a polygonal geographic boundary, and so
on. It's a little more difficult to set up, but it's much more powerful
(and accurate) than a simple lat/lng pair.

The Expressions API that will be part of Django 1.8 would also be useful to
you:

https://docs.djangoproject.com/en/dev/ref/models/expressions/

However, that would be riding the bleeding edge of Django, so unless you're
looking to be particularly adventurous, I'd stick to the more stable
options.


> 2) The computed value is not just useful for the QuerySet, but I need
> also that on client side so I serialize it and I send it using JSON.
> Is possible to make sure that the manager attach the field "distance"
> to the objects in the QuerySet?
>

If it's available for the database to filter, then it will automatically be
on the objects in the QuerySet, which means it will be available for
serialisation.

Yours,
Russ Magee %-)

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

Re: Backup vs Audit

[Russell Keith-Magee]

Hi Andrea,

In short, you don't - at least, not out of the box. That's not what
Django's admin interface is for. Django's admin is a quick-and-dirty CRUD
interface you can throw over some models, with some customisation hooks
that means it has a lifespan beyond initial bootstrapping.

It isn't a sysadmin tool, or a dbadmin tool, or anything like that.

If you want to backup and/or restore your database, you need to use a
database backup tool. There are a range of options, depending on the
database you're using; but I'm not aware of any particularly common options
that are integrated with Django's admin.

Yours,
Russ Magee %-)

On Mon, Dec 8, 2014 at 9:22 PM, Andrea Zakowicz 
wrote:

> Hi I wonder if you are aware of how to backup / restoration database and
> audit from the django admin.
>
> --
> 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/6a51def8-3c9c-4d11-92a8-908257478a1f%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/CAJxq84_PmjmFJ9Rmh4Ew0yPz_gF-aabTXQjGOLMGuqAwP%3DnFAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add another link missing in Chrome

[Russell Keith-Magee]

Hi Timothy,

No two browsers will ever render things *identically*, but it should
certainly be functionally equivalent, and at least bear a striking
resemblance to each other. There certainly shouldn't be a missing button or
anything like that.

My immediate reaction is that you've probably got something cached in your
browser - Chrome caches very aggressively, and sometimes needs to be
politely kicked to get it to refresh some resources. However, if you can
reproduce this problem if you start from scratch, it's definitely worth a
bug report.

Yours,
Russ Magee %-)

On Sat, Dec 6, 2014 at 8:51 PM, Timothy Good  wrote:

> Here is the heart of my question:  Is basic Django code (like in the poll
> tutoiral) supposed to render the same in different browsers? If the answer
> is 'Yes' this looks like a bug.  Thoughts?
>
>
> On Friday, December 5, 2014 11:19:37 AM UTC-5, Timothy Good wrote:
>>
>> Django Users,
>>
>> I am working through polls tutorial part 2 that enhances the admin page.
>> Note that I did search for a solution in the recommended places but while I
>> saw similar complaints, none seemed to match exactly.
>>
>> In poll tutorial 2 it says "At the end of the three current slots you
>> will find an “Add another Choice” link."  But this is not the case in
>> Chrome.
>>
>> If I view source in Chrome I see this function but the addText does not
>> appear.  (I am on the latest Chrome: Version 39.0.2171.71 (64-bit))
>>  This is in the source:
>>
>> 
>>
>> (function($) {
>> $("#choice_set-group .tabular.inline-related tbody tr").tabularFormset({
>> prefix: "choice_set",
>> adminStaticPrefix: '/static/admin/',
>> addText: "Add another Choice",
>> deleteText: "Remove"
>> });
>> })(django.jQuery);
>> 
>>
>>
>>
>>
>> For the heck of it I gave it a try in Safari and it rendered just fine.
>>
>> Here is my code in admin.py:
>>
>> from django.contrib import admin
>> from polls.models import Question, Choice
>>
>> class ChoiceInline(admin.TabularInline):
>> model = Choice
>> extra = 3
>>
>> class QuestionAdmin(admin.ModelAdmin):
>> fieldsets = [
>> (None,   {'fields': ['question_text']}),
>> ('Date information', {'fields': ['pub_date'], 'classes':
>> ['collapse']}),
>> ]
>> inlines = [ChoiceInline]
>>
>> admin.site.register(Question, QuestionAdmin)
>>
>> Any thoughts or is this a known issue?
>>
>> Thanks,
>> Tim
>>
>>
>>
>>
>>
>>
>>
>>
>  --
> 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/e00baaef-353a-4226-9a43-e574d8c07622%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/CAJxq849M7UF6RJF%3D6sH-aXrjShrPJcV3Z2c_kdFxej3c0LYTzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Web and mobile app with Django? Kivy? sth else?

[Russell Keith-Magee]

Hi Mariusz,

It depends how many sharp edges you're willing to live with. I've been
working on a project to allow users to develop native mobile apps in Python:

http://pybee.org/toga/

It's *very* early stage though - nothing close to production ready. There
isn't even really a tutorial for mobile development.

I hesitate mentioning it at all, other than to point out that it is
*possible*, and I'm looking into the space at the moment.

Yours,
Russ Magee %-)

On Fri, Dec 5, 2014 at 10:03 PM, Mariusz Wilk  wrote:

> Thanks for your advice!
> PhoneGap uses JS, HTML and CSS. Is there any way I could do this in Python
> or would it be unneccessarily complicated since maybe there's no
> PhoneGap-type-of-framework for Python?
>
>
> W dniu środa, 3 grudnia 2014 00:56:17 UTC użytkownik Cal Leeming napisał:
>>
>> Hi Mariusz,
>>
>> Short answer - Hack something together in the fastest way possible, don't
>> worry about it being clean, tidy or even tested. Because if you do, you'll
>> still be working on this project in 2 years time... Look at using something
>> like PhoneGap [8], just enjoy the experience and ship it :)
>>
>> If you genuinely want to start learning this stuff, you need to ask
>> yourself what it is you want to work on? Do you want to do backend (e.g.
>> all the server stuff, nothing visual), or do you want to do frontend (all
>> the visual/pretty stuff the user sees), or both? Are you doing this for
>> immediate financial gain [7], or a spiritual journey of self discovery and
>> learning [6]? The world of web dev is changing almost every couple of
>> months, stay on top of your game by reading blog articles from other
>> developers and keeping on top of tech new. Personally I use Feedly [9] to
>> aggregate these feeds into one place. Consider getting an internship
>> somewhere with other good programmers, learning from inspirational people
>> will speed up your personal development massively (I wish someone had told
>> me this 8 years ago).
>>
>> Long answer;
>>
>> Responsive/adaptive design does not necessarily make a good mobile
>> experience, and rarely will you find a mobile app which has the same
>> workflow as the website. Ideally you need to storyboard each experience and
>> wireframe the UX accordingly. Likewise with the UI, colors and sizes which
>> work well on desktop often won't work very well on mobile/tablet
>> (especially if you are designing your desktop site mostly towards PC users,
>> due to the variations in color display).
>>
>> There are tools out there now which allow you to package up your
>> HTML/JS/CSS/images into a native application bundle, meaning you don't have
>> to learn how to write native applications. There are a whole bunch of these
>> products out there [1], but most of them suck, here's why. Building a
>> client side JS application is *hard*, you have to understand the different
>> JS design patterns in order to write clean and stable code, whilst
>> understanding the importance of unit testing [3] and real browser testing
>> [4]. You also have to understand the impact of latency, if you don't
>> compile your assets into a local bundle (instead opting to just wrap a
>> browser window in an IOS app), then your app experience will lag between
>> clicks (because each click is a page load). To get around this you need to
>> build your client side app to be completely independent of the server side,
>> which includes maintaining a view state (e.g. changing/rendering the
>> display upon changes being made). Other libraries exist for doing this such
>> as Ember [5] and others, but they are still quite alpha and have
>> performance concerns too. Also in regards to bundling, there are very few
>> tools out there which will automate this entire process, for example
>> creating a spritesheet of UI images so you don't have to make multiple HTTP
>> asset requests, or embedding the images as base64 in your stylesheet
>> (although that has render performance concerns).
>>
>> Then you also have the API, building a clean RESTful api is difficult and
>> in actual fact may be the wrong approach for your mobile app.. why? Because
>> each API call has a lot of overhead, and this usually results in UI latency
>> if the user has poor signal. There is some work being done to use
>> websockets instead of ajax calls, but this starts to get into quite deep
>> territory.
>>
>> Gonna cut this short, as I try to limit myself to 30 minutes on any given
>> reply. Again don't worry too much about what I've put in the long answer,
>> that's just there to give you some insight into the things you'll start
>> thinking about as you get deeper into your journey.
>>
>> Hope this helps dude
>>
>> Cal
>>
>> [1] Google search for "app maker iphone"
>> [2] http://addyosmani.com/resources/essentialjsdesignpatterns/book/
>> [3] http://qunitjs.com/
>> [4] http://www.seleniumhq.org/
>> [5] http://emberjs.com/
>> [6] http://www.amazon.co.uk/The-Clean-Coder-Professional-
>> Programmers/dp/0137081073
>> [7] http

Re: Seeking for advise on usage MySQL together with MongoDB

[Russell Keith-Magee]

On Fri, Dec 5, 2014 at 8:56 PM, Artie  wrote:

> Good day, Community,
>
> I'm looking for advise on MySQL & MongoDB usage so please let me take your
> time to describe the situation.
>
> I came to work on e-commerce shop of electrical components with about 10
> millions of products. Now all of it stored in awful structure of tables in
> MySQL. Products stored in 10 small tables, each of them represents
> individual manufacturer of products and 1 generalized table, where all 10
> millions of goods is stored. Those big table serves Sphinx search to
> implement search on site.
> All these products being crawled from several APIs and sites on web, so
> this shop is kind of authorized reseller in our region.
>
> The case is that we have to update all products daily and  parsing with
> updating of products takes very long time.
>
> I have an idea to start using MongoDB to update and store products and as
> I think it might take less time than same in MySQL. First question: Am I
> correct with this statement?
>
> Browsing web I've found that some recommend using pymongo, avoiding django
> rather than mongodb for django. So for your opinion is this statement
> correct?
>
> Also it will be highly highly appreciated if you can share your personal
> use experience with MongoDB and any information you think be useful.
>

Hi Artie,

Can I make an alternate suggestion? Get a real database.

In all honesty, I've never heard anyone in the Django community express a
deep love of MySQL or MongoDB. I know people who use MySQL, but when they
admit that, they say "Yeah, I know, but the customer required it" or "Yeah,
I know, but at the time we started it was the only thing Amazon supported".
As for MongoDB, the sentiment is usually "... and that was our first
mistake.".

Personally - I have very little time for MySQL. It gets a number of key
design decisions wrong (for example, InnoDB's implementation of row
referential integrity is *demonstrably* incorrect). It has some default
behaviours that beggar belief (e.g., on MyISAM, by default, a row with a
"WHERE field IS NULL" clause that matches no results, and the previous
statement was an insert, the query will not return no results, but the
primary key of the last row inserted. By design [1][2]). And MySQL's usage
of indexes is woefully naïve - to the point where "performance optimising
for MySQL" often means "Roll out the results of an inner query and pass
them in as arguments, rather than just using a subquery".

[1] https://code.djangoproject.com/ticket/14661
[2] https://groups.google.com/forum/#!topic/django-developers/1BgLit316XA

And then you have MongoDB - a database that exists, as far as I can make
out, to overcome the deficiencies in MySQL. If you'd just started with a
real database, you wouldn't have hit the problems with MySQL, and you
wouldn't have to go looking for an exotic solution to overcome those
problems.

If you're looking for performance, you're going to get much better
performance out of PostgreSQL, for the same price you paid for MySQL, with
the added benefit that PostgreSQL developers appear to have actually
consulted the SQL specification when they implemented their database. They
also have a query planner that will actually *use* indexes, instead of just
keeping them for decoration like MySQL does.

If you're looking for a "schemaless" data store - well, PostgreSQL hstore
fields [3] have you covered. To the extent that people have actually
developed "MongoDB in PostgreSQL" [4]. And those stores outperform MongoDB
[5].

[3] http://www.postgresql.org/docs/9.0/static/hstore.html
[4] https://github.com/torodb/torodb
[5]
http://blogs.enterprisedb.com/2014/09/24/postgres-outperforms-mongodb-and-ushers-in-new-developer-reality/

So - in all honesty, I'd start by reconsidering your initial assumptions.

Yours,
Russ Magee %-)

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

Re: Matching wit XOR

[Russell Keith-Magee]

On Fri, Dec 5, 2014 at 5:24 PM, inoyon artlover KLANGRAUSCH <
inoyonartlo...@googlemail.com> wrote:

> Hi everybody,
>
> need to accomplish a matching in following fashion:
>
> Users have to edit their psychological profile and
> select XOR characteristic on each category.
>
> Qestions:
> 1.
> extroverted: (checkbox)
> or
> introverted: (checkbox)
>
> 2.
> organised: (checkbox)
> or
> spntaneous: (checkbox)
>
> So only ONE choice is possible per question.
> Any suggestions or examples?
>
>
Yes - don't use a checkbox, use a radio button.

Checkboxes are for Yes/No questions that are standalone. They can also be
used to establish "membership of a set" when the list of options is
relatively limited.

If you have a set of choices where the user must select one of a list of
known options, the right input widget is a radio button, not a checkbox.

Yours,
Russ Magee %-)

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

Re: Obtaining content from Git

[Russell Keith-Magee]

On Mon, Nov 24, 2014 at 7:43 PM, martin f krafft 
wrote:

> also sprach Russell Keith-Magee  [2014-11-24
> 11:38 +0100]:
> > Perhaps I wasn't clear.
>
> No, you were. I am just pushing back a little bit because I come
> from another angle and I greatly appreciate your explanations in
> helping me understand the Django way of thinking. So in the hope
> that you now don't feel exploited… ;)
>
> > You might be able to write a mapping to Storage that did some sort
> > of naming trick (e.g., split off a colon at the end of a filename
> > for read, so you could request "/my/file.txt:deadbeef" to request
> > the "deadbeaf" hash of /my/file.txt") - but my point is that the
> > storage API doesn't contain a *natural* endpoint for version
> > information.
>
> Arguably, the ref/hash/date could come from the config, not from the
> file, and suddenly there'd be a 1:1 mapping between a filesystem
> store and a storage that uses Git directly.
>
>
Sure - that could work too. Although I'd question why you'd do this, rather
than just checking out the relevant hash onto the filesystem, and doing a
direct filesystem read.

> And, even if you did this, what you're going to get is a view of
> > your Git repository that tries *really* hard to make it look like
> > just a normal file system.
>
> Yeah, this is an excellent point, especially since I'd probably not
> allow pushes to that Git repository but instead set up some sort of
> polling or regular interval pulling. Then I might just as well use
> a filesystem.
>
> > def myview(request):
> > with open('filename.txt') as datafile:
> > data = datafile.read()
> > return render(request, 'my template.html', {'data': data})
> >
> > You're possibly getting lost by thinking that this is a "Django" thing -
> it
> > isn't. Basic Python is always an option.
>
> Yeah, but I would like to assume that this has been wrapped for
> Django at least one "canonical" time, with all error handling done
> and proper cache integration taken care of.
>
> Because to just start off with a myview() view like you suggest
> above is quickly going to become a full-time project, if you know
> what I mean. ;)
>

Unless I'm missing some important detail, I don't see why. It's a fairly
simple caching layer, and a fairly simple rendering layer. The only
complexities that I can see are the ones related to accessing the Git
repository - and that's the bit that isn't part of a "common" use case.


> > > Have you seen something like this done? Is this also still best
> > > done in a view?
> >
> > Well... yes, I've seen this done before. It's called GitHub :-)
>
> Hehe, that was funny.
>
> But seriously: forget about all of the Git stuff, let's just look at
> the filesystem… at least in my universe, I'd like to assume that the
> idea of reading marked-up data from disk, processing it, caching it
> and then making the data available to templates is such an intuitive
> and standard thing to do that it could even be in Django core — if
> not there, then there ought to be an existing plugin for this.
>

Again - the reason that this isn't in Django is because it's not really
Django's bailiwick. Response-level caching is something that should be
handled at the web server level, and web servers have various ways to
handle this. And if you're going to be even more ruthless about it, I'd be
questioning why you've got a live Django server in the loop at all - if
it's static files, "post processed", then why not pre-render the Github
files to a "rendered" form (possibly in response to a commit trigger), and
simply serve the pre-rendered files as static content.

Yours,
Russ Magee %-)

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

Re: Obtaining content from Git

[Russell Keith-Magee]

On Mon, Nov 24, 2014 at 5:06 PM, martin f krafft 
wrote:

> also sprach Russell Keith-Magee  [2014-11-24
> 07:16 +0100]:
> > The right place is in the view.
> […]
> > If you want to do "interesting" things like retrieve a specific
> > file version, you're not going to be able to use the storage API,
> > because most raw
>
> Interesting perspective you have there, which I can follow very
> well. Thanks!
>
> But let me dig a bit further, nevertheless:
>
> > The storage layer is an abstraction to enable reusable apps. If
> > I write a "user profile" app that needs to store an avatar, then
> > I don't care where that avatar comes from, as long as it's
> > available. It could be on a local filesystem; it could be on
> > a cloud file store (like S3). The storage API lets me do that.
>
> It could come from Git! After all, Git is really a database by
> itself, just like the filesystem could be viewed as a database. So
> somewhere in my idealist brain there's this theory that I could just
> add a Git-storage-plugin to the storage layer and that would cause
> content to be fetched from Git auto-magically if the
> request-for-data by the view (not the HTTP request) matches certain
> criteria and those data are available in Git. If not, then the
> lookup goes to the next storage plugin.
>
> So my view might call some sort of lookup() function, e.g.
>
>   lookup_description(event_id)
>
> which just returns a string. Ordinarily, this string comes from
> pgsql at the moment. What I'd like to see is a way to override this
> function so that instead the data are fetched from
>   git.example.org/myrepo.git, branch=live, file=events/$event_id
>
> Obviously, I could just as well call the Git-specific stuff straight
> from the view, but that would inevitably tie the view to Git. Maybe
> this is what I want, I am just trying to explain how I approached
> this and what led me to ask the question the way I did.
>

Perhaps I wasn't clear. Of course an avatar could come from a git store. My
point is that it's not a natural mapping. A file system is a mapping
between a path name and a binary blob. Git has an additional layer - the
path name, *plus* a historical version (referenced either by a hash, or a
date). And you can't arbitrarily write to any point in a Git tree. Ok...
you can if you're willing to have orphan nodes, but if you're thinking
about version control in the traditional sense, a git repository can only
be written to the "end" of history, but read from any point in it's history.

You might be able to write a mapping to Storage that did some sort of
naming trick (e.g., split off a colon at the end of a filename for read, so
you could request "/my/file.txt:deadbeef" to request the "deadbeaf" hash of
/my/file.txt") - but my point is that the storage API doesn't contain a
*natural* endpoint for version information.

And, even if you did this, what you're going to get is a view of your Git
repository that tries *really* hard to make it look like just a normal file
system. All the interesting features will, by necessity of the interface,
be buried. If you actually want to do anything interesting based on the
fact that you're using a git store under the hood, you're better served
working closer to the metal.

> If you're just looking to read the *current* value in a git
> > repository, then just use normal filesystem storage over a normal
> > git checkout.
>
> Yeah, this might well be the best option, also in terms of
> performance, unless I want to keep track of blob hashes to avoid
> doing the whole branch→tree→blob lookup every time, which the
> filesystem "caches" for me.
>
> Do you know of a simple example that fetches data from the
> filesystem? I am being lazy here as I am sure there's plenty, so
> feel free to RTFM me! ;) However, maybe you know a very good example
> that makes everything so clear and then I'd really appreciate this
> over wading through the various means. I know Django has provisions
> for serving static files, but somehow it seems like that's not what
> I want… (since the files are not actually static and a given path
> could return different data on subsequent calls)
>
> A simple example that fetches data from the filesystem? Sure:

def myview(request):
with open('filename.txt') as datafile:
data = datafile.read()
return render(request, 'my template.html', {'data': data})

You're possibly getting lost by thinking that this is a "Django" thing - it
isn't. Basic Python is always an option.

Furthermore, I'd actually like to post-process the data. The Git
>

Re: Obtaining content from Git

[Russell Keith-Magee]

On Mon, Nov 24, 2014 at 1:45 PM, martin f krafft 
wrote:

> also sprach Russell Keith-Magee  [2014-11-24
> 00:42 +0100]:
> > The problem is that there isn't one. There's several :-)
> >
> > I'm aware of at least 3:
> >
> > https://pypi.python.org/pypi/GitPython/0.3.2.1
> > https://pypi.python.org/pypi/pygit2
> > https://pypi.python.org/pypi/dulwich
>
> I am aware of those and I was wondering more about the glue on the
> Django-side of things, i.e. how the storage plugin/layer would work.
>
> I am pretty inexperienced with Django, hence I find it hard to even
> figure out where the sensible place to do this would be.
>

The right place is in the view.

At the simplest level, a view is just a function that converts a request
into a response. "Normal" Django template rendering (i.e., return
render(request, "mytemplate.html", {'object': obj}) ) hides a lot of detail
- but all it's really doing is opening a file on disk (from one of a couple
of a known locations - the template directories), parsing that template,
rendering it with a context, and returning it to the user.

A simple "hello world" view will develop "obj" by doing database queries -
but the information can come from any other data source that is relevant.
You might hit a non-relational store (such as Redis), or a search engine
(like ElasticSearch), or do some sort of calculation based on the GET/POST
arguments provided. In your case, you'll be taking the GET/POST values,
plus the URL parameters, and using them to identify a "resource" in your
Git tree; your git calls will extract that resource; and then you can
either return that resource literally as your response (with an appropriate
content type), or pass the resource to a template to be rendered.

Thinking about the storage layer is going deeper than you need to go. The
storage layer is an abstraction to enable reusable apps. If I write a "user
profile" app that needs to store an avatar, then I don't care where that
avatar comes from, as long as it's available. It could be on a local
filesystem; it could be on a cloud file store (like S3). The storage API
lets me do that.

The storage API isn't there to abstract all possible concepts of storage
that might exist, and just because you'll be accessing a notional file
system, doesn't mean that access needs to be done through the storage API -
it's fine to just open the file.

While you probably *could* write a storage plugin that would read a git
repository, that's not really what the storage API is for.

If you're just looking to read the *current* value in a git repository,
then just use normal filesystem storage over a normal git checkout. If you
want to do "interesting" things like retrieve a specific file version,
you're not going to be able to use the storage API, because most raw
filesystems don't have a concept of versioning.

Yours,
Russ Magee %-)

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

Re: Obtaining content from Git

[Russell Keith-Magee]

On Sun, Nov 23, 2014 at 5:28 AM, martin f krafft 
wrote:

> Hello,
>
> we have a Django project with a few pages that come from Git.
> Currently, Apache rewrite rules serve those files statically (and
> they make use of the same template/CSS as Django does, so the user
> does not actually notice), and it's a massive hack and pain to keep
> up-to-date.
>
> Hence I was thinking: how much trouble would it be to have Django
> reach into Git rather than its database and obtain data there to be
> filled into template slots? Ideally, there'd be the possibility of
> running a filter (e.g. reStructuredText) between Git and the
> template rendering.
>
> I've seen http://luispedro.org/software/git-cms, but that does way
> more than just sourcing from Git. And it's not immediately obvious
> to me how it even does the Git interaction.
>
> What I envision is a storage layer (with optional caching) that
> either fetches from the filesystem (with a Git checkout, using mtime
> for cache expiration), or directly from a local Git repo (using
> either commit or blob hash for cache expiration).
>
> Does anyone know of such a module? Would it be hard to write? Where
> would one start?
>

The problem is that there isn't one. There's several :-)

I'm aware of at least 3:

https://pypi.python.org/pypi/GitPython/0.3.2.1
https://pypi.python.org/pypi/pygit2
https://pypi.python.org/pypi/dulwich

These are all Python wrappers around the Git API - and, in the case of
dulwich, a full re-implementation of git in Python. Using these APIs, you
should be able to retrieve an file with an arbitrary hash, the same as you
would at the command line.

I haven't used any of them myself, so I can't comment on which one is
best/most stable/most reliable/fastest, but:

 * Yes, they exist

 * Yes, you could use these modules to retrieve information from the git
checkout as part of a view

 * Yes, that data could then be passed to a template, either directly, or
after post-processing with a filter of some kind.

Yours,
Russ Magee %-)

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

Re: What on earth is causing this "naive datetime" warning?

[Russell Keith-Magee]

Hi Daniel,

A naïve datetime is a datetime that doesn't have a timezone. If you have
USE_TZ=True enabled in your settings file (which is the default for new
projects), Django expects you to fully specify datetime objects with a
timezone; if you don't, you get the warning you've seen, because the
datetime you've provided is ambiguous. Django can guess, but there's no
guarantee that the guess will be correct.

The django.utils.timezone package provides a few utilities to convert naïve
datetimes to timezone-enabled datetimes. I'd also suggest looking into
pytz, which provides a regularly updated database of the world's timezones.

Yours,
Russ Magee %-)

On Wed, Nov 19, 2014 at 8:38 PM, Daniel Grace  wrote:

> Hi,
>
> Here is my model:
> class Flow(models.Model):
> ref = models.CharField(max_length=32)
> state = models.ForeignKey(State)
> flow_type = models.ForeignKey(Type)
> created = models.DateTimeField(db_index=True, auto_now_add=True)
> modified = models.DateTimeField(db_index=True, auto_now=True)
> version = models.IntegerField()
> def __str__(self):
> return str(self.id)
>
> Here is my test.py file:
> import warnings
> warnings.filterwarnings(
> 'error', r"DateTimeField .* received a naive datetime",
> RuntimeWarning, r'django\.db\.models\.fields')
>
>
> In settings.py:
> TIME_ZONE = 'Europe/London'
> USE_TZ = True
>
> Here is what happens when I run the test script:
> >python manage.py test flow
> Creating test database for alias 'default'...
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "C:\landy\lib\site-packages\django\core\management\__init__.py",
> line 385
> , in execute_from_command_line
> utility.execute()
>   File "C:\landy\lib\site-packages\django\core\management\__init__.py",
> line 377
> , in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File
> "C:\landy\lib\site-packages\django\core\management\commands\test.py", lin
> e 50, in run_from_argv
> super(Command, self).run_from_argv(argv)
>   File "C:\landy\lib\site-packages\django\core\management\base.py", line
> 288, in
>  run_from_argv
> self.execute(*args, **options.__dict__)
>   File
> "C:\landy\lib\site-packages\django\core\management\commands\test.py", lin
> e 71, in execute
> super(Command, self).execute(*args, **options)
>   File "C:\landy\lib\site-packages\django\core\management\base.py", line
> 338, in
>  execute
> output = self.handle(*args, **options)
>   File
> "C:\landy\lib\site-packages\django\core\management\commands\test.py", lin
> e 88, in handle
> failures = test_runner.run_tests(test_labels)
>   File "C:\landy\lib\site-packages\django\test\runner.py", line 147, in
> run_test
> s
> old_config = self.setup_databases()
>   File "C:\landy\lib\site-packages\django\test\runner.py", line 109, in
> setup_da
> tabases
> return setup_databases(self.verbosity, self.interactive, **kwargs)
>   File "C:\landy\lib\site-packages\django\test\runner.py", line 299, in
> setup_da
> tabases
> serialize=connection.settings_dict.get("TEST_SERIALIZE", True),
>   File "C:\landy\lib\site-packages\django\db\backends\creation.py", line
> 374, in
>  create_test_db
> test_flush=True,
>   File "C:\landy\lib\site-packages\django\core\management\__init__.py",
> line 115
> , in call_command
> return klass.execute(*args, **defaults)
>   File "C:\landy\lib\site-packages\django\core\management\base.py", line
> 338, in
>  execute
> output = self.handle(*args, **options)
>   File
> "C:\landy\lib\site-packages\django\core\management\commands\migrate.py",
> line 160, in handle
> executor.migrate(targets, plan, fake=options.get("fake", False))
>   File "C:\landy\lib\site-packages\django\db\migrations\executor.py", line
> 63, i
> n migrate
> self.apply_migration(migration, fake=fake)
>   File "C:\landy\lib\site-packages\django\db\migrations\executor.py", line
> 97, i
> n apply_migration
> migration.apply(project_state, schema_editor)
>   File "C:\landy\lib\site-packages\django\db\migrations\migration.py",
> line 107,
>  in apply
> operation.database_forwards(self.app_label, schema_editor,
> project_state, ne
> w_state)
>   File
> "C:\landy\lib\site-packages\django\db\migrations\operations\fields.py", l
> ine 131, in database_forwards
> schema_editor.alter_field(from_model, from_field, to_field)
>   File "C:\landy\lib\site-packages\django\db\backends\schema.py", line
> 509, in a
> lter_field
> self._alter_field(model, old_field, new_field, old_type, new_type,
> old_db_pa
> rams, new_db_params, strict)
>   File "C:\landy\lib\site-packages\django\db\backends\schema.py", line
> 612, in _
> alter_field
> new_default = self.effective_default(new_field)
>   File "C:\landy\lib\site-packages\django\db\backends\schema.py", line
> 183, in e
> ffective_default
> default = field.get_db_prep_save(default, self.connection)
>   File "C:\landy\lib\site-packag

Re: Django + Database Connections

[Russell Keith-Magee]

On Wed, Nov 12, 2014 at 11:42 AM, Edward Armes 
wrote:

> HI guys,
>
> Thanks for your responses, they have indeed answered all my questions
> pretty much as I was mainly looking for information on how to modify how
> Django accesses it's ORM layer. However from your answer it seems that it
> would be better that I do it at the model layer. I apologize for being so
> vague in my question it was semi-deliberate as I wanted to avoid people
> posting application specific solutions like "Use module X and do Y" and
> often when you ask questions reguarding internals on open-source projects
> and other places (i.e. Stack Overflow) you normaly get a load people
> responding with "why?" which for understandable reasons I wanted to avoid.
>
> To follow on from this I have a few more quick questions:-
>
> - If my understanding is correct the Django admin interface uses the model
> layer? If so while learning Django I remember reading (although I can't
> find the link now) that if you use a model that doesn't use Django database
> layer the admin code doesn't work? if this is the case why so?
>

Yes with an if, no with a but :-)

Out of the box, Django's admin only works with Django models. This is
because most of what the admin is doing is based around model introspection
- it's not making database calls per se, it's using the fact that you've
registered your "Product" model, and a Django model has internal mechanisms
to answer questions like "what fields do you have, and what type are those
fields". From that, Django Admin can build a basic CRUD workflow around the
model.

If your data store *isn't* a Django model, then Django's admin doesn't have
any metadata about the model to work with, so it doesn't have any way to
build that workflow.

That said - one of the driving forces behind the Meta Refactor that I
referenced was to formalize what that metadata interface actually is, so in
principle, *any* data model could be displayed in Django's admin, as long
as it is self-describing in the way the Django admin is expecting. As a
proof of concept of this Daniel (the GSoC student responsible) built a
wrapper that lets you browse your Gmail inbox in Django's admin - after
all, email is just a bunch of models like Message, Thread, Folder etc, and
there's an API for manipulating them. That API doesn't use a database, but
it does do Create, retrieve, update and delete, so Django's admin can be
used as a visualisation for it.


> - Secondly would I be correct in thinking that by having asynchronous
> models it would break the default forms and views lthat are included ike
> the wonderful Admin package?
>

Again - only "out of the box". If you make it quack like a Django-shaped
duck by providing an interface that is compatible with Django's
expectations, then it *should* work, and the Meta refactor that is
hopefully coming for 1.8 should make this a lot easier.

Yours,
Russ Magee %-)

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

Re: set the css class of a form widget based on the data

[Russell Keith-Magee]

Hi Michael,

The best bet would be to write a custom widget, and override the render()
method. render() takes the name of the widget, the value to render, and a
dictionary of attr values. In your subclass, you can override this method
to inject the additional attributes based on the provided value - something
like:

class MyWidget(TextInput):
def render(self, name, value, attrs=None):
if value == SPECIAL VALUE:
attrs['class'] = 'class1 class2'
return super(MyWidget, self).render(name, value, attrs)

This is an oversimplification - there's a few extra edge cases you'll need
to account for - if attrs is none, or if 'class' already exists - but the
idea should hopefully make sense.

Yours,
Russ Magee %-)



On Wed, Nov 12, 2014 at 9:25 PM, Michael 
wrote:

> Hi,
>
> The ``attrs`` attribute of a widget allows to define the html attributes.
> For example, setting it to ``widget.attrs['class'] = 'class1 class2'`` will
> add ``class="class1 class2"`` on the rendered widget.
>
> However, how can I set them based on the data? I display an update form
> and I'd like to change the CSS class based on the data that is going to be
> displayed when the form is rendered.
>
> Where could I check for the data in order to change the ``attrs`` property
> of the widget before it is rendered?
>
> 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/3569acd7-5bec-4df9-8960-4952b3fee8fb%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/CAJxq849qJkr6GrqK-6FQ7phpgAAR%3Dk3c_0CWNsv%3DyuJy9rXWzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django + Database Connections

[Russell Keith-Magee]

Hi Edward,

On Tue, Nov 11, 2014 at 12:30 AM, Edward Armes 
wrote:

> Hi there,
>
> I am currently looking at Django for a personal project. While I
> understand how a lot of it works I can't wrap my head around how the actual
> DB querying is done specifically what part of Django actually looks at the
> database (I'm not talking about Manager, Models or Querysets, but the
> actual parts of Django that use the ORM's to get data from the database
> itself).
>
> If a reason is required without going into detail on my current half-baked
> idea, I'm specifically looking how to handle database operations that have
> a significant return time by marrying asynchronous environments with
> synchronous ones. While it may be more efficant to use a non-Django
> database handler. For now I want to look into using the Django framework
> without needing additional imports.
>
>
It's not that a *reason* is required - it's that it's not entirely clear
what you're asking for.

The thing is, Django *itself* doesn't do a lot of querying - Django is a
template system, and a forms layer, and a database ORM, all nicely
integrated, so you can easily compose the pieces to do something useful.
There are places where the forms layer will issue queries (e.g., if you
want to display a form that has a  representing the available
options from a model), but that's really at the level of "give me a
queryset that represents the options I want to display".

The only part of Django *itself* that "uses" Django is the contents of the
contrib apps - most importantly, contrib.admin, but there are others.

The idea of marrying async and synchronous environments isn't a new one -
it was the subject of a Google Summer of Code project this year, the result
of which will hopefully be committed to trunk for 1.8. The core of that
project was to formalise the API around Django's model layer so that you
can write a "duck typed" object that will be a substitute for a Django
model (subject to certain constraints and limitations). Search the
Django-Developer archive for "Meta Refactor" if you want more details.
However, that won't let you get away "without needing additional imports" -
at some point, you're going to need to import your async layer, because
Django doesn't have one.

I don't know if any of this helps... hopefully it does :-)

Yours,
Russ Magee %-)

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