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.

contrib admin changeform_view and atomic

[Alessandro Pasotti]

Hi,

With Django >= 1.6, changeform_view is wrapped in atomic(), this broke
my application where the model's save() has couple of triggers (I'm in
Postgresql) and a raw query in a post_save signal, the error is the
infamous "cannot alter table because of pending triggers...".

This is what I'm referring to:
https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1325

I've done a quick and dirty patch on my app's admin.py overriding
changeform_view and this works fine but, in a perfect world, this
atomic() behavior in the admin change view should be configurable in
the settings, is there any chance to get this in the core if I file a
ticket and provide a patch?


-- 
Alessandro Pasotti
w3:   www.itopen.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/CAL5Q6703U-f6Bx88n%3DuzOJ3gEKk-S%3DMEueMpHNSmXF6re9yddg%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: Suggestion

[Johan Hendriks]

Op 18-03-15 om 07:38 schreef Jay Prasad:

Hi All,

I'm started Pyhthon and django ,give me some suggestions and which 
sites was good .help me.thank you all

--
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/c07141eb-9d7d-48f5-8d10-4b4ac5718d0d%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.




http://www.tangowithdjango.com/ is a nice tutorial, but also the 
tutorial on the django site itself.
If you want other resources, there are a lot of video's on the youtube 
channel that covers django and python.



Good luck.


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

Re: How to make request ie GET/POST to soap (windows web service ) in Django?

[SHINTO PETER]

Thank you James Schneider & Andrew Farrell

On Wednesday, 18 March 2015 21:46:33 UTC+5:30, SHINTO PETER wrote:
>
> How to make request ie GET/POST  to soap (windows web service ) in 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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2632a791-21bf-4bf9-98cb-03250bb7bca2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.6's lifespan for security updates?

[Stephen Gallagher]

> On Mar 19, 2015, at 3:18 AM, Russell Keith-Magee  
> wrote:
> 
> 
>> 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 :-)
> 

I think you'll find that this is a bit overstated. Customers install plenty of 
software that isn't provided by Red Hat. I think you might be amazed at how 
popular the public Extra Packages for Enterprise Linux repository is (it's a 
sub-project of Fedora that provides many packages from the Fedora collection 
built for RHEL).

What they don't do (except in dire need) is install alternative versions of 
software that *is* provided by their support contract. This is because for most 
companies, the added features aren't worth the self-maintenance. No one who 
isn't an OS vendor can keep up with the security issues on all of that software.


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

Yes and no, but it's not much of an answer because the double-edged sword here 
is that the Software Collections also have a much shorter supported lifespan 
than the main operating system (which guarantees a stable platform for at least 
ten years). For most companies, rebuilding "that one internal app we maintain" 
every three years is unrealistic. Not everyone is Twitter or Netflix, doing 
multiple deploys an hour.

Speaking anecdotally, the average lifetime I've seen of customer-produced 
internal apps is usually about 7-8 years (generally equivalent to whenever they 
moved to the latest RHEL release until the moment it goes out of support... 
sometimes past that, unwisely). You do not want to know how many datacenters 
are still running RHEL 4 and even RHEL 3.




> Yours,
> Russ Magee %-)
> 
> -- 
> 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/B74QJaqA0b4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/CAJxq848g%2BUavE0giY2cogrh%3DwY2OzxbeHX9Bv0_SXFD0v0L0oQ%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 t

Django builds wrong sql query.

[Алексей Широков]

*I have the following code:*

package_queryset = Package.objects.extra(
where=[(' "document_package"."id" IN (SELECT DISTINCT ON 
("document_id") "id"'
' FROM "document_package"'
' WHERE "status" NOT IN 
(\'unknown\','
'
\'deleted\')'
' ORDER BY "document_id" ASC,'
'  "completed" DESC,'
'  "last_modified" DESC)')]
)

document_queryset = Document.objects.select_related(
'contractor',
'stagcy',
'period',
).filter(
packages=package_queryset.all(),
).extra(
select={
'st_result': ('(CASE'
  ' WHEN ("document_package"."state"::json -> 
\'result\' ->> \'status\') = \'failure\' THEN 2'
  ' WHEN ("document_package"."state"::json -> 
\'result\' ->> \'status\') = \'warning\' THEN 1'
  ' ELSE 0'
  '  END)'),
'st_sending': ('(CASE'
   ' WHEN ("document_package"."state"::json -> 
\'sending\' ->> \'status\') = \'failure\' THEN 4'
   ' WHEN ("document_package"."state"::json -> 
\'sending\' ->> \'status\') = \'warning\' THEN 3'
   ' WHEN ("document_package"."state"::json -> 
\'sending\' ->> \'status\') = \'unknown\' THEN 2'
   ' WHEN ("document_package"."state"::json -> 
\'sending\' ->> \'status\') = \'success\' THEN 1'
   ' ELSE 0'
   '  END)'),
'st_exchange': ('(CASE'
' WHEN ("document_package"."state"::json -> 
\'exchange\' ->> \'status\') = \'success\' THEN 1'
' ELSE 0'
'  END)'),
}
).order_by(
'-st_result',
'-st_sending',
'st_exchange',
'-packages__last_modified',
)

*result:*

SELECT ...
FROM "document_document"
INNER JOIN "document_package" ON ("document_document"."id" = 
"document_package"."document_id")
INNER JOIN "contractor_contractor" ON ("document_document"."contractor_id" 
= "contractor_contractor"."id")
INNER JOIN "stateagency_stateagency" ON ("document_document"."stagcy_id" = 
"stateagency_stateagency"."id")
LEFT OUTER JOIN "document_period" ON ("document_document"."period_id" = 
"document_period"."id")
WHERE "document_package"."id" IN
(SELECT U0."id"
 FROM "document_package" U0
 WHERE ((*"document_package"*."id" IN   // <-- 
*must be U0*   (SELECT DISTINCT ON ("document_id") "id"
FROM "document_package"
WHERE "status" NOT IN ('unknown',
   'deleted')
ORDER BY "document_id" ASC, "completed" DESC, 
"last_modified" DESC))
AND NOT (U0."status" IN (completed_manually,
 completed_success
ORDER BY "st_result" DESC,
 "st_sending" DESC,
 "st_exchange" ASC,
 "document_package"."last_modified" DESC


I tested it on the versions 1.7 and 1.8

-- 
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/0b8a553e-4f44-49bd-889c-302758804dc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django builds wrong sql query.

[Tim Graham]

Try ditching .extra() and using the expressions API in Django 1.8. We're 
trying to make everything that's possible with .extra() available through 
better APIs so try to avoid it as even if there is a bug, it's probably 
unlikely to be fixed.

On Thursday, March 19, 2015 at 9:11:39 AM UTC-4, Алексей Широков wrote:
>
> *I have the following code:*
>
> package_queryset = Package.objects.extra(
> where=[(' "document_package"."id" IN (SELECT DISTINCT ON 
> ("document_id") "id"'
> ' FROM "document_package"'
> ' WHERE "status" NOT IN 
> (\'unknown\','
> '
> \'deleted\')'
> ' ORDER BY "document_id" ASC,'
> '  "completed" DESC,'
> '  "last_modified" DESC)')]
> )
>
> document_queryset = Document.objects.select_related(
> 'contractor',
> 'stagcy',
> 'period',
> ).filter(
> packages=package_queryset.all(),
> ).extra(
> select={
> 'st_result': ('(CASE'
>   ' WHEN ("document_package"."state"::json -> 
> \'result\' ->> \'status\') = \'failure\' THEN 2'
>   ' WHEN ("document_package"."state"::json -> 
> \'result\' ->> \'status\') = \'warning\' THEN 1'
>   ' ELSE 0'
>   '  END)'),
> 'st_sending': ('(CASE'
>' WHEN ("document_package"."state"::json -> 
> \'sending\' ->> \'status\') = \'failure\' THEN 4'
>' WHEN ("document_package"."state"::json -> 
> \'sending\' ->> \'status\') = \'warning\' THEN 3'
>' WHEN ("document_package"."state"::json -> 
> \'sending\' ->> \'status\') = \'unknown\' THEN 2'
>' WHEN ("document_package"."state"::json -> 
> \'sending\' ->> \'status\') = \'success\' THEN 1'
>' ELSE 0'
>'  END)'),
> 'st_exchange': ('(CASE'
> ' WHEN ("document_package"."state"::json -> 
> \'exchange\' ->> \'status\') = \'success\' THEN 1'
> ' ELSE 0'
> '  END)'),
> }
> ).order_by(
> '-st_result',
> '-st_sending',
> 'st_exchange',
> '-packages__last_modified',
> )
>
> *result:*
>
> SELECT ...
> FROM "document_document"
> INNER JOIN "document_package" ON ("document_document"."id" = 
> "document_package"."document_id")
> INNER JOIN "contractor_contractor" ON ("document_document"."contractor_id" 
> = "contractor_contractor"."id")
> INNER JOIN "stateagency_stateagency" ON ("document_document"."stagcy_id" = 
> "stateagency_stateagency"."id")
> LEFT OUTER JOIN "document_period" ON ("document_document"."period_id" = 
> "document_period"."id")
> WHERE "document_package"."id" IN
> (SELECT U0."id"
>  FROM "document_package" U0
>  WHERE ((*"document_package"*."id" IN   // <-- 
> *must be U0*   (SELECT DISTINCT ON ("document_id") "id"
> FROM "document_package"
> WHERE "status" NOT IN ('unknown',
>'deleted')
> ORDER BY "document_id" ASC, "completed" DESC, 
> "last_modified" DESC))
> AND NOT (U0."status" IN (completed_manually,
>  completed_success
> ORDER BY "st_result" DESC,
>  "st_sending" DESC,
>  "st_exchange" ASC,
>  "document_package"."last_modified" DESC
>
>
> I tested it on the versions 1.7 and 1.8
>

-- 
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/a76f9238-ad10-4d6b-bf99-19dc2750dc42%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: newbie question

[VMD]

On Wednesday, March 18, 2015 at 12:51:22 PM UTC-6, Avraham Serour wrote:
>
> short - use a view
>
> follow the tutorial, yes you will learn how to store and retrieve values 
> from a database, and I understand that you don't need that yet but the 
> tutorial is very brief, you won't waste your time with advanced topics you 
> don't need
>

I understand you have good intentions with your answer. I am trying not to 
be frustrated with it. I don't think I would call the tutorial "very brief" 
I have skimmed the tutorial and didn't find (notice) the answer. Why not 
point me to an answer to my question?

Trying not to be frustrated ;)
Thanks
VMD
 

>  
>
On Wed, Mar 18, 2015 at 8:08 PM, VMD > 
> wrote:
>
>> New to django and web frameworks in general. The tutorial is great for 
>> database type apps but I want to solve a different problem to start with 
>> and am kinda stuck. All I want to do is allow a user to input a value(s) 
>> and return the output of a python function using that value(s). Could 
>> someone point me to an example or guide for doing this.
>> For example:
>>
>> Accept input X, Y
>> Return the output of myadder(x,y)
>>
>> def myadder(x,y):
>> return x+y
>>
>>  -- 
>> 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/4f1c37bd-0f91-4708-aa40-e1dd0db44e09%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/91dfe6d9-dc90-42ae-a1e2-c680f718d125%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.8 post_save without recursion

[Alexander MacQueen]

The post_save 'created' argument could help if you only wanted to trigger 
the signal when the Person was first created:

@receiver(post_save, sender=Person)
def do(instance, *args, **kwargs):
if kwargs.get('created'):
instance.ok = True
instance.save()



On Friday, March 13, 2015 at 5:35:46 AM UTC, Neto wrote:
>
> What is the best way to avoid recursion when using post_save?
>
> @receiver(post_save, sender=Person)
> def do(sender, instance, *args, **kwargs):
> instance.ok = True
> instance.save()
>
>

-- 
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/09db8258-208d-4b05-8d1e-1a5cae9ce262%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: newbie question

[Javier Guerra Giraldez]

On Wed, Mar 18, 2015 at 9:41 PM, VMD  wrote:
> I have skimmed the tutorial and didn't find (notice) the answer. Why not
> point me to an answer to my question?


that's exactly the point.  your question assumes Django works in some
specific way, and there should be a simple answer for a simple need.

but i don't think you assumptions are correct, if you knew how Django
(and frameworks in general) work, your question might be very
different, and the answer much simpler and better in general.

really, doing the tutorial is a very good investment of your time.


-- 
Javier

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

Re: newbie question

[Andrew Farrell]

The other commenters are right that reading the tutorial is a good use of
your time.
https://docs.djangoproject.com/en/1.7/intro/tutorial03/
is the section relevant to your question.

On Thu, Mar 19, 2015 at 10:39 AM, Javier Guerra Giraldez  wrote:

> On Wed, Mar 18, 2015 at 9:41 PM, VMD  wrote:
> > I have skimmed the tutorial and didn't find (notice) the answer. Why not
> > point me to an answer to my question?
>
>
> that's exactly the point.  your question assumes Django works in some
> specific way, and there should be a simple answer for a simple need.
>
> but i don't think you assumptions are correct, if you knew how Django
> (and frameworks in general) work, your question might be very
> different, and the answer much simpler and better in general.
>
> really, doing the tutorial is a very good investment of your time.
>
>
> --
> Javier
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAFkDaoQ0MOT57JCKfTjxWn6CkypeP2POm%3DF90Vn%3DF88dYDDQdg%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/CA%2By5TLZVUzRqL_Tcwwq%2BD2p70XdXbW2E%3DYQ1adavbJOmxggLow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.6's lifespan for security updates?

[Carl Meyer]

On 03/19/2015 01:01 AM, Russell Keith-Magee wrote:
> On Thu, Mar 19, 2015 at 12:05 PM, James Bennett  > wrote:
> 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.

I agree with all of this. I think that the Django core team will not
provide this extended support for 1.6 (because it gives the impression
that Python 2.6 is a supported and secure platform, which is only true
for the subset of our user base on certain extended-support distros),
and I don't think that extended-support releases of 1.6 should or will
ever appear on pypi.python.org/pypi/Django.

But I think that anyone who feels the need for this extended support can
feel free to raise the resources to make it happen and do it in a github
fork. If someone planning to maintain such a fork applied for
pre-notification of security releases, and could demonstrate significant
support for their effort, I would be in favor of that application.

And I think that if "that person" ends up being Tim Graham, as an
individual outside of his duties as Django Fellow, that's his choice and
I don't see any problem with it. We've already established a precedent,
several times over, for members of the core team to be paid for certain
tasks that parts of the community need or want that aren't getting done
otherwise. I would not support the DSF or Django core team sponsoring
the fundraising for this effort, but if a part of the community raises
the funds and Tim wants to accept said funds and do the work, more power
to him, as long as it doesn't detract from his other work as Django Fellow.

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: Django builds wrong sql query.

[Алексей Широков]

Thanks for your reply, I will try...

-- 
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/d23dbcab-6165-400c-9540-6ec12c210daa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django and PostgreSQL - Amazon RDS new SSL certificate

[Flávio Junior]

 

When I logged in my AWS account I got the following message:

*"We have determined that your RDS database instances are using the 
existing SSL certificate (rds-ca-2010) and this certificate will be updated 
on 23 March 2015. You must follow the steps here to update your application 
with the new SSL certificate bundle (rds-ca-2015) before 23 March 2015 
20:00 UTC. If you have not updated your application with the new 
certificate by then, you may lose connectivity to your RDS instances."*

I use a RDS PostgreSQL instance in a Django app. My settings are pretty 
vanilla:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': config('DB_NAME'),
'USER': config('DB_USER'),
'PASSWORD': config('DB_PASSWORD'),
'HOST': config('DB_HOST'),
'PORT': config('DB_PORT'),
'ATOMIC_REQUESTS': True
}
}


Do I need to make the certificates migration?

Thanks,
Flávio

-- 
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/e7eefb2f-8b67-4796-b2be-b79635f2463f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.6's lifespan for security updates?

[Tim Graham]

Discussion to be continued on django-developers: 
https://groups.google.com/d/topic/django-developers/69fOquu8v-U/discussion

On Thursday, March 19, 2015 at 12:18:46 PM UTC-4, Carl Meyer wrote:
>
> On 03/19/2015 01:01 AM, Russell Keith-Magee wrote: 
> > On Thu, Mar 19, 2015 at 12:05 PM, James Bennett   
> > > wrote: 
> > 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. 
>
> I agree with all of this. I think that the Django core team will not 
> provide this extended support for 1.6 (because it gives the impression 
> that Python 2.6 is a supported and secure platform, which is only true 
> for the subset of our user base on certain extended-support distros), 
> and I don't think that extended-support releases of 1.6 should or will 
> ever appear on pypi.python.org/pypi/Django. 
>
> But I think that anyone who feels the need for this extended support can 
> feel free to raise the resources to make it happen and do it in a github 
> fork. If someone planning to maintain such a fork applied for 
> pre-notification of security releases, and could demonstrate significant 
> support for their effort, I would be in favor of that application. 
>
> And I think that if "that person" ends up being Tim Graham, as an 
> individual outside of his duties as Django Fellow, that's his choice and 
> I don't see any problem with it. We've already established a precedent, 
> several times over, for members of the core team to be paid for certain 
> tasks that parts of the community need or want that aren't getting done 
> otherwise. I would not support the DSF or Django core team sponsoring 
> the fundraising for this effort, but if a part of the community raises 
> the funds and Tim wants to accept said funds and do the work, more power 
> to him, as long as it doesn't detract from his other work as Django 
> Fellow. 
>
> Carl 
>
>

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

{{STATIC_URL }} or {% static "...." %} What`s the correct to use?

[Fellipe Henrique]

Hi,

In my template, when I made a reference to my Static folder.. what's the
correct usage?

{{STATIC_URL }} or {% static "" %}

Django 1.7 and Python 3

Thanks!

T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
*Blog: http://fhbash.wordpress.com/ *
*GitHub: https://github.com/fellipeh *
*Twitter: @fh_bash*

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

Re: {{STATIC_URL }} or {% static "...." %} What`s the correct to use?

[Stephen J. Butler]

It says right in the docs what to do:

https://docs.djangoproject.com/en/1.7/howto/static-files/

On Thu, Mar 19, 2015 at 7:57 PM, Fellipe Henrique  wrote:
> Hi,
>
> In my template, when I made a reference to my Static folder.. what's the
> correct usage?
>
> {{STATIC_URL }} or {% static "" %}
>
> Django 1.7 and Python 3
>
> Thanks!
>
> T.·.F.·.A.·. S+F
> Fellipe Henrique P. Soares
>
> e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
> Blog: http://fhbash.wordpress.com/
> GitHub: https://github.com/fellipeh
> Twitter: @fh_bash
>
> --
> 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/CAF1jwZGwzdxJK4r9ZDrbXbaov3m9pkFRusnnyM3fLHU41Y--RA%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/CAD4ANxW3L1DXsX-2XFSNZZq62qHtO6B%3DgOHPOn%3D9MmP5witdAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Looking for a Django consultant

[Joe Landrigan]

I'm trying to build a program that will allow churches to offer services 
and network with their members and other churches.  As you may have guessed 
from the words "church" and "service" my budget is limited, but I am 
willing to pay.

I need some help resolving issues around per-object permissions.  I think I 
want to use django-guardian, but would welcome any means of speeding the 
final result along.

Please contact me with any questions.

Thank you,
Joe Landrigan
Email: my_last_name[3:] + 'x...@gmail.com'

PS: Is there a better place to post requests like 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/0da1d75a-d905-4351-8f40-7c41e69973f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: {{STATIC_URL }} or {% static "...." %} What`s the correct to use?

[Fellipe Henrique]

Thanks, but I already try the docs, but my static files doesn't  show!

Show me 404 error.. even when I run manage.py collectstatic

T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
*Blog: http://fhbash.wordpress.com/ *
*GitHub: https://github.com/fellipeh *
*Twitter: @fh_bash*

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

Re: {{STATIC_URL }} or {% static "...." %} What`s the correct to use?

[Vijay Khemlani]

What URL is being generated in the final HTML?, and does that path match
the one you have in the static folder in your app?

Also, if your are on debug mode, you don't need to run collectstatic

On Thu, Mar 19, 2015 at 10:19 PM, Fellipe Henrique 
wrote:

> Thanks, but I already try the docs, but my static files doesn't  show!
>
> Show me 404 error.. even when I run manage.py collectstatic
>
> T.·.F.·.A.·. S+F
> *Fellipe Henrique P. Soares*
>
> e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \
> 's/(.)/chr(ord($1)-2*3)/ge'
> *Blog: http://fhbash.wordpress.com/ *
> *GitHub: https://github.com/fellipeh *
> *Twitter: @fh_bash*
>
> --
> 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/CAF1jwZF_RWXWCQTozSO%2BODqNuTyz-29VZ0pvjsw7Jsdosuw31Q%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/CALn3ei061gH5ov3gNnV12uN9aSL_%2BB5-oUWJuYXSmoC6YOSk1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: {{STATIC_URL }} or {% static "...." %} What`s the correct to use?

[Stephen J. Butler]

Some questions you need to answer then:

1. Does the URL to the static resource appear properly in your rendered HTML?
2. Did you configure your web server properly so that the STATIC_ROOT
appears at the right location?
3. After running collectstatic does the STATIC_ROOT directory have the
expected structure?
4. Are file and directory permissions correct so that the server can read them?
5. Can you enter the URL to the static resource in your browser and view it?
6. Is there any information in your web server error_log file that helps?

On Thu, Mar 19, 2015 at 8:19 PM, Fellipe Henrique  wrote:
> Thanks, but I already try the docs, but my static files doesn't  show!
>
> Show me 404 error.. even when I run manage.py collectstatic
>
> T.·.F.·.A.·. S+F
> Fellipe Henrique P. Soares
>
> e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
> Blog: http://fhbash.wordpress.com/
> GitHub: https://github.com/fellipeh
> Twitter: @fh_bash
>
> --
> 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/CAF1jwZF_RWXWCQTozSO%2BODqNuTyz-29VZ0pvjsw7Jsdosuw31Q%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/CAD4ANxXUrw1VRYtxdboHp_Zg9dbG8wYCMuQjFu35j%3DTLKHe05g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: {{STATIC_URL }} or {% static "...." %} What`s the correct to use?

[Mike Dewhirst]

On 20/03/2015 12:19 PM, Fellipe Henrique wrote:

Here is a fairly typical static file template line ...

href="{{STATIC_URL}}css/styles.css" media="screen"/>


... and to see where that fits, insert something like this in your local 
settings. You will discover any bludners fairly quickly ...


print(('BASE_DIR = %s %s' % (BASE_DIR, '(project root)')))
print(('SETTINGS_DIR = %s' % SETTINGS_DIR))
print(('MEDIA_ROOT = %s %s' % (MEDIA_ROOT, '(store uploaded images)')))
print(('MEDIA_URL = %s %s' % (MEDIA_URL, '(serve uploaded 
images)')))

print(('STATIC_ROOT = %s %s' % (STATIC_ROOT, '(collectstatic dest)')))
print(('STATIC_URL = %s %s' % (STATIC_URL, '(serve css, js etc)')))
for i in enumerate(STATICFILES_DIRS, 1):
print(('STATICFILES_DIRS#%s = %s' % i))
for i in enumerate(TEMPLATE_DIRS, 1):
print(('TEMPLATE_DIRS#%s = %s' % i))




Thanks, but I already try the docs, but my static files doesn't  show!

Show me 404 error.. even when I run manage.py collectstatic

T.·.F.·.A.·.     S+F
*Fellipe Henrique P. Soares*

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
/Blog: http://fhbash.wordpress.com//
/GitHub:Â https://github.com/fellipeh/
/Twitter: @fh_bash/

--
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/CAF1jwZF_RWXWCQTozSO%2BODqNuTyz-29VZ0pvjsw7Jsdosuw31Q%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/550B84C5.1030706%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Data migration fails because contenttypes not yet ready

[Daniel Hahler]

Hi Markus,

thanks for your answer and explanations!

I am now using a management hook to call the `loaddata` command manually
via the post_migrate signal:

% cat project/appname/management/__init__.py
# Handle initial data in Django 1.7+.

from django.db.models import signals
from django.core.management import call_command

def load_initial_data(app_config, sender, **kwargs):
if sender.label == __package__.split(".")[0]:
call_command('loaddata', 'initial_data.yaml', app_label='appname')

signals.post_migrate.connect(load_initial_data, weak=False)

Using a normal migration for this does not work when `flushdb` is called
during tests, and using pytest/pytest-django with the `--reuse-db` option.

Is there another option to fix this in Django 1.7+?

The TransactionTestCase is often only required because of the 
LiveServerTestCase.

Using serialized_rollback might be an option 
(https://code.djangoproject.com/ticket/22487),
but then it tends to be slower than not using "--reuse-db".

(With pytest-django the tests are not being ordered like with Django
currently, but that could be done - although I don't think it would help
much by itself.)


Thanks,
Daniel.

On 22.01.2015 14:23, Markus Holtermann wrote:

> The sanest way to generate all ContentTypes and Permissions is to
> migrate those two apps explicitly before migrating the remaining apps:
> 
> $ python manage.py migrate contenttypes
> $ python manage.py migrate auth
> $ python manage.py migrate

That's not really an option for tests, is it?

> initial ideas emitting a signal after each migration (no ticket yet
> afaik). The latter could be used to tackle the above problem.

Yes, that seems sensible.

> If you want to create a specific permission during a migration, do the 
> following in `RunPython`:
> 
> def forwards(apps, schema_editor): 
> Permission = apps.get_model('auth', 'Permission')
> Permission.objects.create(...)

If I understand it correctly this would cause the same problem, wouldn't
it - if you run all migrations in a single step (during tests)?

It would also not be there after `flushdb`.

> The django-migration-fixture app seems to do some crazy stuff in the
> management command that I'm not going to speculate about how long it's
> going to work. That is completely undocumented and internal API.

Yes, but that part is only used to auto-generate the migration file for
you. In the end is generated a file with a `RunPython` operation.

> Apart from that, the (de)serializers in django.core.serializers
> (specifically .python.Deserializer) use the global apps for
> deserialization. Thus, a fixture referring to a model that is later
> removed/renamed, or refers to a field that doesn't exist later or must
> not be null, cannot be applied when you run the migrations on an empty
> database.

Good to know. It

> 
> /Markus
> 
> On Thursday, January 22, 2015 at 12:43:33 PM UTC+1, Daniel Hahler wrote:
> 
> Hello,
> 
> I was having the same issue as Torsten: it does not appear to be possible 
> to load initial data related to contenttypes or auth during migrations.
> 
> As for the problem with contenttypes reported by Torsten, a workaround 
> appears to be calling `update_all_contenttypes` manually from your migration 
> (from django.contrib.contenttypes.management).
> 
> But then there's the problem with creating auth.groups.
> 
> I've tried the following via `RunPython`:
> 
> from django.contrib.auth.management import create_permissions
> create_permissions(apps.get_app_config('auth'), verbosity=0)
> 
> This aborts because `app_config.models_module` is None:
> 
> app_config.__dict__
> {'models_module': None, 'name': 'auth', 'models': 
> OrderedDict([('group_permissions', ), ...]), 
> 'module': None, 'label': 'auth', 'verbose_name': 'Auth'}
> 
> Is this related to https://code.djangoproject.com/ticket/23822 
>  ("Serialize model managers in 
> migrations"), and would be possible in Django 1.8?
> 
> I am trying to use https://github.com/alexhayes/django-migration-fixture 
> , which is meant to 
> provide a convenient wrapper around the initial_data fixtures (files). My PR 
> with the changes mentioned above is viewable at: 
> https://github.com/alexhayes/django-migration-fixture/pull/2/files 
> .
> 
> What is the suggested way to have initial data with Django 1.7, given 
> that initial_data is not used for apps with migrations, and RunPython has the 
> above shortcomings?
> 
> 
> Thanks,
> Daniel.
> 
> Am Dienstag, 21. Oktober 2014 19:42:34 UTC+2 schrieb Torsten Bronger:
> 
> Hallöchen!
> 
> Markus Holtermann writes:
> 
> > Are you talking about Django 1.7 migrations or South? In the
> > former case you