ANN: eGenix mxODBC Connect 2.1.5 - Remote Python Database Interface

[eGenix Team: M.-A. Lemburg]

ANNOUNCING

  eGenix.com mxODBC Connect

  Remote Python Database Interface

Version 2.1.5


 mxODBC Connect is our commercially supported client-server product for
   connecting Python applications to relational databases
 in a truly platform independent way.


This announcement is also available on our website for online reading:
http://www.egenix.com/company/news/eGenix-mxODBC-Connect-2.1.5-GA.html



INTRODUCTION

The mxODBC Connect Database Interface for Python allows users to
easily connect Python applications to all major databases on the
market today in a highly portable, convenient and secure way.

Python Database Connectivity the Easy Way
-

Building on our mxODBC database interface for Python, mxODBC Connect
is designed as client-server application, so you no longer need to
find production quality database drivers for all platforms you target
with your Python application.

Instead, you use an easy to install royalty-free Python client library
which connects directly to the mxODBC Connect database server over the
network.

This makes mxODBC Connect a great basis for writing cross-platform
multi-tier database applications and utilities in Python, especially
if you run applications that need to communicate with databases such
as MS SQL Server and MS Access, Oracle Database, IBM DB2 and Informix,
Sybase ASE and Sybase Anywhere, MySQL, PostgreSQL, SAP MaxDB and many
more, that run on Windows or Linux machines.

Ideal for Database Driven Client Applications
-

By removing the need to install and configure ODBC drivers on the
client side and dealing with complicated network setups for each set
of drivers, mxODBC Connect greatly simplifies deployment of database
driven client applications, while at the same time making the network
communication between client and database server more efficient and
more secure.

For more information, please have a look at the mxODBC Connect product
page, in particular, the full list of available features.

For more information, please see the product page:

http://www.egenix.com/products/python/mxODBCConnect/



NEWS

mxODBC Connect 2.1.5 is a patch level release of our successful mxODBC
Connect database product. It includes these enhancements and fixes:

Security Enhancements
-

 * Prevent mxODBC Connect Server from listening on sockets which are
   unbound due to a configuration error. The OS will typically assign
   a random port and listen on all interfaces, which can pose a
   security issue.

mxODBC Connect Enhancements
---

 * Add allow_clients configuration variable to [Session] config
   section of the mxODBC Connect Server. This allows overriding the
   list accepted client IP addresses/networks and helps to e.g. allow
   connections from clients not on the server's interface networks.

 * Added "connections" shortcut support for allow_clients to easily
   access the list of configured networks defined by the connection
   sections.

 * Added "all" and "localhost" shortcuts support for allow_clients to
   simplify allowing any client IP address or only the local machine.


For the full set of changes, including those of the 2.1 series of
mxODBC Connect, please check the mxODBC Connect change log:

http://www.egenix.com/products/python/mxODBCConnect/changelog.html



UPGRADING

You are encouraged to upgrade to this latest mxODBC Connect release.
When upgrading, please always upgrade both the server and the client
installations to the same version - even for patch level releases.

We will give out 20% discount coupons for upgrade purchases going from
mxODBC Connect Server 1.x to 2.1 and 50% coupons for upgrades from
mxODBC Connect Server 2.x to 2.1. Please contact the eGenix.com Sales
Team (sa...@egenix.com) with your existing license serials for
details.

Users of our stand-alone mxODBC product will have to purchase new
licenses from our online shop in order to use mxODBC Connect.

You can request free 30-day evaluation licenses by visiting our
web-site or writing to sa...@egenix.com, stating your name (or the
name of the company) and the number of eval licenses that you need.

http://www.egenix.com/products/python/mxODBCConnect/#Evaluation



DOWNLOADS

The download archives as well as instructions for installation and
configuration of the product can be found on the product page:

http://www.egenix.com/products/python/mxODBCConnect/

If you want to try the package, jump straight to

Reverse query name clashe with a M2M and through

[Gagaro]

Hello,

I have a situation I don't really understand. I have the following models:

class Wishlist(models.Model):
wine = models.ForeignKey('Wine')
user = models.ForeignKey('User')


class Wine(models.Model):
name = models.CharField(max_length=32)


class User(models.Model):
name = models.CharField(max_length=32)
wishlist = models.ManyToManyField(Wine, through=Wishlist)

And the following error:

models_test.Wishlist.user: (fields.E303) Reverse query name for 
> 'Wishlist.user' clashes with field name 'User.wishlist'.
> HINT: Rename field 'User.wishlist', or add/change a related_name argument 
> to the definition for field 'Wishlist.user'.


Is that an intended behaviors? In my understanding, there is no related 
relation created for through models (IE: we can't directly get the Wishlist 
instance from the User one). Why would the names clash in this case? And 
why does it clashes on *wishlist*, the reverse relation shouldn't be 
*wishlist_set* and not *wishlist*?

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/abf0aef4-ffe8-4252-ae5b-7ac9f2150f1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issues with django-storages and gunicorn processes

[Mike Herring]

Sorry, I am using Mezzanine, which has a Media Library that uses 
filebrowser_safe. But this issue isn't specific to Mezzanine.

The problem exists in django-storages. The entries property is stored in 
local memory for each gunicorn worker process. So if you save or delete a 
file in one worker process, the others don't know about the change.

I've solved this issue by clearing the entries property and repopulating it 
from AWS at the beginning of each page request. I don't know if that's the 
ideal solution, but it works.

On Thursday, October 22, 2015 at 9:22:01 AM UTC-4, Vijay Khemlani wrote:
>
> Media Library? I'm not aware of something like that in django-storages
>
> On Wed, Oct 21, 2015 at 5:22 PM, Mike Herring  > wrote:
>
>> I am using django-storages to store media files in Amazon S3.
>>
>> Gunicorn spaws three worker processes, each running their own copy of 
>> S3BotoStorage. When I go into filebrowser and upload a file, the current 
>> worker process adds it to its entries list, and therefore knows that the 
>> file exists. When I go back to the Media Library, it switches to a 
>> different worker process and says the file doesn't exist.
>>
>> Is there any way to get around this? Should django-storages share it's 
>> entries list across processes? Can it be run as a singleton? 
>>
>> -- 
>> 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/5e1a0cf8-2ece-43a5-8199-78cbcbbfbdb3%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/36fa120f-4440-40cd-8476-6aa51458c869%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reverse query name clashe with a M2M and through

[Simon Charette]

Hi Gagaro,

Intermediate models are just like other in this regard, they create a 
related relation hence the reported clash.

You should either add related_name='+' on your Wishlist related fields or 
give them a unique name.

Simon

Le vendredi 23 octobre 2015 06:01:30 UTC-4, Gagaro a écrit :
>
> Hello,
>
> I have a situation I don't really understand. I have the following models:
>
> class Wishlist(models.Model):
> wine = models.ForeignKey('Wine')
> user = models.ForeignKey('User')
>
>
> class Wine(models.Model):
> name = models.CharField(max_length=32)
>
>
> class User(models.Model):
> name = models.CharField(max_length=32)
> wishlist = models.ManyToManyField(Wine, through=Wishlist)
>
> And the following error:
>
> models_test.Wishlist.user: (fields.E303) Reverse query name for 
>> 'Wishlist.user' clashes with field name 'User.wishlist'.
>> HINT: Rename field 'User.wishlist', or add/change a related_name argument 
>> to the definition for field 'Wishlist.user'.
>
>
> Is that an intended behaviors? In my understanding, there is no related 
> relation created for through models (IE: we can't directly get the Wishlist 
> instance from the User one). Why would the names clash in this case? And 
> why does it clashes on *wishlist*, the reverse relation shouldn't be 
> *wishlist_set* and not *wishlist*?
>
> 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/f7b01ec8-dcd3-4df9-83d2-8f9e61e92d64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reverse query name clashe with a M2M and through

[Gagaro]

Hi Simon, thanks for the answer, it cleared some things up.

However, I still have a question. The reverse relation is *wishlist_set* by 
default. Why is Django bothered if the attribute is name *wishlist* (I 
would understand if I named my attribute *wishlist_set*)?

On Friday, 23 October 2015 15:40:42 UTC+2, Simon Charette wrote:
>
> Hi Gagaro,
>
> Intermediate models are just like other in this regard, they create a 
> related relation hence the reported clash.
>
> You should either add related_name='+' on your Wishlist related fields or 
> give them a unique name.
>
> Simon
>
> Le vendredi 23 octobre 2015 06:01:30 UTC-4, Gagaro a écrit :
>>
>> Hello,
>>
>> I have a situation I don't really understand. I have the following models:
>>
>> class Wishlist(models.Model):
>> wine = models.ForeignKey('Wine')
>> user = models.ForeignKey('User')
>>
>>
>> class Wine(models.Model):
>> name = models.CharField(max_length=32)
>>
>>
>> class User(models.Model):
>> name = models.CharField(max_length=32)
>> wishlist = models.ManyToManyField(Wine, through=Wishlist)
>>
>> And the following error:
>>
>> models_test.Wishlist.user: (fields.E303) Reverse query name for 
>>> 'Wishlist.user' clashes with field name 'User.wishlist'.
>>> HINT: Rename field 'User.wishlist', or add/change a related_name 
>>> argument to the definition for field 'Wishlist.user'.
>>
>>
>> Is that an intended behaviors? In my understanding, there is no related 
>> relation created for through models (IE: we can't directly get the Wishlist 
>> instance from the User one). Why would the names clash in this case? And 
>> why does it clashes on *wishlist*, the reverse relation shouldn't be 
>> *wishlist_set* and not *wishlist*?
>>
>> 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/3c41497b-94d7-4c65-8bef-7a29b00e540f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reverse query name clashe with a M2M and through

['Tom Evans' via Django users]

On Fri, Oct 23, 2015 at 3:27 PM, Gagaro  wrote:
> However, I still have a question. The reverse relation is wishlist_set by
> default. Why is Django bothered if the attribute is name wishlist (I would
> understand if I named my attribute wishlist_set)?

The message doesn't mention the reverse relation names that conflict,
it mentions the names of *fields* whose relation names would conflict.

> Reverse query name for 'Wishlist.user' clashes with field name 
> 'User.wishlist'.
> HINT: Rename field 'User.wishlist', or add/change a related_name argument to 
> the definition for field 'Wishlist.user'.

'Wishlist.user' and 'User.wishlist' are the names of the fields being
discussed. The meaning might be clearer with some added words:

The reverse query name for the field 'Wishlist.user' clashes with
the field 'User.wishlist' - they are both ''wishlist_set'.
HINT: Rename field 'User.wishlist', or add/change a related_name
argument to the definition for field 'Wishlist.user'.

Cheers

Tom

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

Re: Reverse query name clashe with a M2M and through

[Simon Charette]

Hi Gagaro,

Upon further investigation it looks like the following thing is happening, 
you find have a similar example in the documentation 

.

When you define an explicit through model Django generates a query name to 
allow direct reference to the intermediate relationship.

This query name is not customizable and is generated by lower casing the 
intermediate model name ('wishlist' in your case and 'membership' in the 
linked one).

The clash you're getting here is between this implicit query name and your 
User.wishlist field and would manifest itself if your were to call 
User.objects.filter(wishlist__...) where Django couldn't differentiate the 
field from the *through query name*.

I guess the clash message could be more clear when a clash happens with 
this implicit query name.

Simon

Le vendredi 23 octobre 2015 10:27:26 UTC-4, Gagaro a écrit :
>
> Hi Simon, thanks for the answer, it cleared some things up.
>
> However, I still have a question. The reverse relation is *wishlist_set* 
> by default. Why is Django bothered if the attribute is name *wishlist* (I 
> would understand if I named my attribute *wishlist_set*)?
>
> On Friday, 23 October 2015 15:40:42 UTC+2, Simon Charette wrote:
>>
>> Hi Gagaro,
>>
>> Intermediate models are just like other in this regard, they create a 
>> related relation hence the reported clash.
>>
>> You should either add related_name='+' on your Wishlist related fields or 
>> give them a unique name.
>>
>> Simon
>>
>> Le vendredi 23 octobre 2015 06:01:30 UTC-4, Gagaro a écrit :
>>>
>>> Hello,
>>>
>>> I have a situation I don't really understand. I have the following 
>>> models:
>>>
>>> class Wishlist(models.Model):
>>> wine = models.ForeignKey('Wine')
>>> user = models.ForeignKey('User')
>>>
>>>
>>> class Wine(models.Model):
>>> name = models.CharField(max_length=32)
>>>
>>>
>>> class User(models.Model):
>>> name = models.CharField(max_length=32)
>>> wishlist = models.ManyToManyField(Wine, through=Wishlist)
>>>
>>> And the following error:
>>>
>>> models_test.Wishlist.user: (fields.E303) Reverse query name for 
 'Wishlist.user' clashes with field name 'User.wishlist'.
 HINT: Rename field 'User.wishlist', or add/change a related_name 
 argument to the definition for field 'Wishlist.user'.
>>>
>>>
>>> Is that an intended behaviors? In my understanding, there is no related 
>>> relation created for through models (IE: we can't directly get the Wishlist 
>>> instance from the User one). Why would the names clash in this case? And 
>>> why does it clashes on *wishlist*, the reverse relation shouldn't be 
>>> *wishlist_set* and not *wishlist*?
>>>
>>> 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/f6239228-b316-4a38-be77-d0ac66410758%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reverse query name clashe with a M2M and through

[Gagaro]

On Friday, 23 October 2015 16:35:32 UTC+2, Tom Evans wrote:
>
> 'Wishlist.user' and 'User.wishlist' are the names of the fields being 
> discussed. The meaning might be clearer with some added words: 
>
> The reverse query name for the field 'Wishlist.user' clashes with 
> the field 'User.wishlist' - they are both ''wishlist_set'. 
> HINT: Rename field 'User.wishlist', or add/change a related_name 
> argument to the definition for field 'Wishlist.user'. 
>

Yes but the relations names would be *wishlist_set* on *User* and *user_set* 
on *Wishlist*? I see no conflict there.

-- 
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/2982535d-7857-414e-921e-aff968223537%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reverse query name clashe with a M2M and through

[Gagaro]

Indeed, that makes sense!

As you said, the issue is that the error message is exactly the same than 
for a "normal" conflict.

Thank you for looking it up.

On Friday, 23 October 2015 16:40:46 UTC+2, Simon Charette wrote:
>
> Hi Gagaro,
>
> Upon further investigation it looks like the following thing is happening, 
> you find have a similar example in the documentation 
> 
> .
>
> When you define an explicit through model Django generates a query name to 
> allow direct reference to the intermediate relationship.
>
> This query name is not customizable and is generated by lower casing the 
> intermediate model name ('wishlist' in your case and 'membership' in the 
> linked one).
>
> The clash you're getting here is between this implicit query name and your 
> User.wishlist field and would manifest itself if your were to call 
> User.objects.filter(wishlist__...) where Django couldn't differentiate the 
> field from the *through query name*.
>
> I guess the clash message could be more clear when a clash happens with 
> this implicit query name.
>
> Simon
>
> Le vendredi 23 octobre 2015 10:27:26 UTC-4, Gagaro a écrit :
>>
>> Hi Simon, thanks for the answer, it cleared some things up.
>>
>> However, I still have a question. The reverse relation is *wishlist_set* 
>> by default. Why is Django bothered if the attribute is name *wishlist* 
>> (I would understand if I named my attribute *wishlist_set*)?
>>
>> On Friday, 23 October 2015 15:40:42 UTC+2, Simon Charette wrote:
>>>
>>> Hi Gagaro,
>>>
>>> Intermediate models are just like other in this regard, they create a 
>>> related relation hence the reported clash.
>>>
>>> You should either add related_name='+' on your Wishlist related fields 
>>> or give them a unique name.
>>>
>>> Simon
>>>
>>> Le vendredi 23 octobre 2015 06:01:30 UTC-4, Gagaro a écrit :

 Hello,

 I have a situation I don't really understand. I have the following 
 models:

 class Wishlist(models.Model):
 wine = models.ForeignKey('Wine')
 user = models.ForeignKey('User')


 class Wine(models.Model):
 name = models.CharField(max_length=32)


 class User(models.Model):
 name = models.CharField(max_length=32)
 wishlist = models.ManyToManyField(Wine, through=Wishlist)

 And the following error:

 models_test.Wishlist.user: (fields.E303) Reverse query name for 
> 'Wishlist.user' clashes with field name 'User.wishlist'.
> HINT: Rename field 'User.wishlist', or add/change a related_name 
> argument to the definition for field 'Wishlist.user'.


 Is that an intended behaviors? In my understanding, there is no related 
 relation created for through models (IE: we can't directly get the 
 Wishlist 
 instance from the User one). Why would the names clash in this case? And 
 why does it clashes on *wishlist*, the reverse relation shouldn't be 
 *wishlist_set* and not *wishlist*?

 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/fca6eeca-71b3-4a46-bec8-20a2be1910da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Iterating over 2 arrays or 1 record array in Django

[C. Kirby]

When you have duplicate keys in a python dict only the second gets saved. 
You can also refer to positions in tuples with . notation in templates. So 
something like:

Python code:

import numpy as npfrom django.template import Template, Context, loaderfrom 
django.conf import settings

dtype={
'names' : ('name','offset'),
'formats' : ('U20','U20')}

instance= np.zeros(3,dtype)


instance[0]=('xga_control_reg','008')
instance[1]=('i_cmd_REG','012')
instance[2]=('i_ee_cmd_reg','016')

t=Template(The Django Template below)
c=Context({"instance":instance})print(t.render(c))


template:

   generated with parser version 1.09--
library ieee;
use ieee.std_logic_1164.all;

package regfile
  (
{% for i in instance%}
   Name is  {{i.0}}  "{{i.1}}" 
{%endfor%}

   ).""")


-- 
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/e32e61ab-ee44-420a-a17f-0bac6583af22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

solution to static file loading issue on 1.8

[Becka R.]

Hi,

I just spent  hours on this problem, and (at last) stumbled into the Stack 
Overflow answer, and wanted to preserve this for posterity.

I'm using Django 1.8, and wasn't able to get my static files to load on my 
local server.  I finally found the Stack Overflow answe 
r
 
that made all the difference - pasted below.

I haven't seen this in the official docs for Django 1.8.  

Snippet below: 

I put this in my settings.py:

STATICFILES_FINDERS = (
"django.contrib.staticfiles.finders.FileSystemFinder",
"django.contrib.staticfiles.finders.AppDirectoriesFinder",)
STATICFILES_DIRS = (
os.path.join(BASE_DIR, "static"),)

-- 
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/b39b9768-24fe-4459-9d8f-8d68e2194f46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

High Performance Django Videos Kickstarter

[JJ Zolper]

I was one of the original backers for the book and now the Lincoln Loop guys 
are doing some High Performance Django Videos.

For anyone that can help us push this Kickstarter over the top that would be 
greatly appreciated.

https://www.kickstarter.com/projects/1704706557/high-performance-django-videos/description

Here are some details per the Kickstarter:

We will produce a series of screencasts giving viewers an "over-the-shoulder" 
look at how we build out a deployment system using the best practices described 
in the book. We'll start from scratch and work our way up to a high performance 
site running in the cloud.

Topics Covered

Virtual machines with Vagrant and VirtualBox
Configuration management with Salt
Salt organization and best practices
Django project organization and deployment
Starting and managing services
Configuring uWSGI, Postgres, Nginx, Varnish, Redis, etc.
Using encryption to protect secrets in Salt
Infrastructure automation with Terraform and Salt Cloud (using Digital Ocean 
and Amazon Web Services as examples)
Basic service orchestration/discovery
Load balancing with Nginx, Varnish, and Amazon's ELB
Simple versioning and rollback strategy
General Linux configuration and server hardening

Thanks to all,

JJ

-- 
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/c052405d-da00-43b6-9ab0-6e2a33dd2166%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: solution to static file loading issue on 1.8

[Tim Graham]

Hi Becka,

You've provided the default value for STATICFILES_FINDERS so putting that 
in your settings shouldn't make a difference. An example of 
STATICFILES_DIRS is given at:

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

If you have a suggestion about how to improve the docs that would be 
welcome.

On Friday, October 23, 2015 at 12:18:13 PM UTC-4, Becka R. wrote:
>
> Hi,
>
> I just spent  hours on this problem, and (at last) stumbled into the Stack 
> Overflow answer, and wanted to preserve this for posterity.
>
> I'm using Django 1.8, and wasn't able to get my static files to load on my 
> local server.  I finally found the Stack Overflow answe 
> r
>  
> that made all the difference - pasted below.
>
> I haven't seen this in the official docs for Django 1.8.  
>
> Snippet below: 
>
> I put this in my settings.py:
>
> STATICFILES_FINDERS = (
> "django.contrib.staticfiles.finders.FileSystemFinder",
> "django.contrib.staticfiles.finders.AppDirectoriesFinder",)
> STATICFILES_DIRS = (
> os.path.join(BASE_DIR, "static"),)
>
>

-- 
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/abb6e0e5-0719-4d33-83b5-dadc48c17713%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: solution to static file loading issue on 1.8

[Becka R.]

Hi, 

I'd love to understand why, exactly, it did make a difference.  All I know 
for sure is that after four hours of trying various possibilities,  this is 
what removed the error. 

Thanks!

On Friday, October 23, 2015 at 10:25:23 AM UTC-7, Tim Graham wrote:
>
> Hi Becka,
>
> You've provided the default value for STATICFILES_FINDERS so putting that 
> in your settings shouldn't make a difference. An example of 
> STATICFILES_DIRS is given at:
>
> https://docs.djangoproject.com/en/1.8/howto/static-files/
>
> If you have a suggestion about how to improve the docs that would be 
> welcome.
>
> On Friday, October 23, 2015 at 12:18:13 PM UTC-4, Becka R. wrote:
>>
>> Hi,
>>
>> I just spent  hours on this problem, and (at last) stumbled into the 
>> Stack Overflow answer, and wanted to preserve this for posterity.
>>
>> I'm using Django 1.8, and wasn't able to get my static files to load on 
>> my local server.  I finally found the Stack Overflow answe 
>> r
>>  
>> that made all the difference - pasted below.
>>
>> I haven't seen this in the official docs for Django 1.8.  
>>
>> Snippet below: 
>>
>> I put this in my settings.py:
>>
>> STATICFILES_FINDERS = (
>> "django.contrib.staticfiles.finders.FileSystemFinder",
>> "django.contrib.staticfiles.finders.AppDirectoriesFinder",)
>> STATICFILES_DIRS = (
>> os.path.join(BASE_DIR, "static"),)
>>
>>

-- 
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/f16ec345-4890-4876-a9e9-dda445c0b748%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: solution to static file loading issue on 1.8

[Tim Graham]

Did you try reading the link I provided? If so, what is unclear?

On Friday, October 23, 2015 at 1:36:43 PM UTC-4, Becka R. wrote:
>
> Hi, 
>
> I'd love to understand why, exactly, it did make a difference.  All I know 
> for sure is that after four hours of trying various possibilities,  this is 
> what removed the error. 
>
> Thanks!
>
> On Friday, October 23, 2015 at 10:25:23 AM UTC-7, Tim Graham wrote:
>>
>> Hi Becka,
>>
>> You've provided the default value for STATICFILES_FINDERS so putting that 
>> in your settings shouldn't make a difference. An example of 
>> STATICFILES_DIRS is given at:
>>
>> https://docs.djangoproject.com/en/1.8/howto/static-files/
>>
>> If you have a suggestion about how to improve the docs that would be 
>> welcome.
>>
>> On Friday, October 23, 2015 at 12:18:13 PM UTC-4, Becka R. wrote:
>>>
>>> Hi,
>>>
>>> I just spent  hours on this problem, and (at last) stumbled into the 
>>> Stack Overflow answer, and wanted to preserve this for posterity.
>>>
>>> I'm using Django 1.8, and wasn't able to get my static files to load on 
>>> my local server.  I finally found the Stack Overflow answe 
>>> r
>>>  
>>> that made all the difference - pasted below.
>>>
>>> I haven't seen this in the official docs for Django 1.8.  
>>>
>>> Snippet below: 
>>>
>>> I put this in my settings.py:
>>>
>>> STATICFILES_FINDERS = (
>>> "django.contrib.staticfiles.finders.FileSystemFinder",
>>> "django.contrib.staticfiles.finders.AppDirectoriesFinder",)
>>> STATICFILES_DIRS = (
>>> os.path.join(BASE_DIR, "static"),)
>>>
>>>

-- 
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/8f9be9af-fda2-4b3e-b1a3-3892dd7fb5c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Template variables not showing up in web-page

[CTA2052]

Hello All,

This may be the most basic question to ask and believe me it does not come 
without much research and frustration, but I just can't seem to make it 
work. So I do apologize ahead of time for even having to post it. I am very 
new to django (2-months), python(4-months) and in fact programming in 
general. I have reviewed the online doc sevral times now and various books 
and tutorials trying to find the answer.

However, I can't seem to get my template variables to render within the web 
page (crazy I know).

I've tried this many different ways and finally backed-up and stripped-down 
the code to see what it is I'm missing

*Here is what I have right now in the veiw:*

def response_page(request):
  
myv = " fun fun fun "
context = {'affirmation': myv}
return render('/response_page/', context )


*Here is the template:*




{% extends "base.html" %}
{% load static %}
{% load crispy_forms_tags %}




challenge_engine_response


{% block content %}
Testing 1,2,3


 I am having so much {{ affirmation }}   

Back to Home Page


{% endblock %}



Everything shows up as expected except the variable "affirmation"  which of 
course should render as "fun fun fun".

I am sure I am missing something silly, but what?
Thanks in advance for the help.  I have very little hair left at this point 
(ha).

Thank you all!

Humbly yours,
CTA2052

-- 
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/5f78b5c5-0652-479f-9ffc-8cd2604967b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template variables not showing up in web-page

[Dheerendra Rathor]

signature for request is render(request, template_name, context, **kwargs)

So it should be like render(request, 'response_page.html', context=context)

On Sat, 24 Oct 2015 at 01:21 CTA2052  wrote:

> Hello All,
>
> This may be the most basic question to ask and believe me it does not come
> without much research and frustration, but I just can't seem to make it
> work. So I do apologize ahead of time for even having to post it. I am very
> new to django (2-months), python(4-months) and in fact programming in
> general. I have reviewed the online doc sevral times now and various books
> and tutorials trying to find the answer.
>
> However, I can't seem to get my template variables to render within the
> web page (crazy I know).
>
> I've tried this many different ways and finally backed-up and
> stripped-down the code to see what it is I'm missing
>
> *Here is what I have right now in the veiw:*
>
> def response_page(request):
>
> myv = " fun fun fun "
> context = {'affirmation': myv}
> return render('/response_page/', context )
>
>
> *Here is the template:*
>
>
> 
>
> {% extends "base.html" %}
> {% load static %}
> {% load crispy_forms_tags %}
>
> 
> 
> 
> challenge_engine_response
> 
> 
> {% block content %}
> Testing 1,2,3
>
>
>  I am having so much {{ affirmation }}   
>
> Back to Home Page
>
> 
> {% endblock %}
> 
>
>
> Everything shows up as expected except the variable "affirmation"  which
> of course should render as "fun fun fun".
>
> I am sure I am missing something silly, but what?
> Thanks in advance for the help.  I have very little hair left at this
> point (ha).
>
> Thank you all!
>
> Humbly yours,
> CTA2052
>
> --
> 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/5f78b5c5-0652-479f-9ffc-8cd2604967b8%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/CAByqUgjzhF-36x11T%3DZocVhsRcE71N_nd6grtTRZAMkdq5KRsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: migrate error

[Mike Dewhirst]

On 23/10/2015 4:23 PM, Christoph Knapp wrote:

Ahh OK, the only explanation I have, is that someone already tried to
use django on the legacy database and the djando tables were already
there. The inspectdb tool put them in the models.py file which caused
the error. I did what you said and it worked. I just looked at the
documentation of the db and those tables were not in there.


Yes. Sounds reasonable. The other way it can happen is that the legacy 
db was actually created by a Django project and both Admin and Auth were 
installed apps.




Thanks

Christoph


On Thursday, October 22, 2015 at 11:31:11 PM UTC+2, Mike Dewhirst wrote:

On 22/10/2015 10:40 PM, Christoph Knapp wrote:
 > Hi,
 > I have a legacy database and used "python manage.py inspectdb >
 > models.py" to create a models.py file. After I modified the file all
 > errors went away when I makemigrations. This step works without
problems
 > on the only app I have in my project. When I go "python manage.py
 > migrate" I get the following error.
 >
 > Operations to perform:
 > Â  Synchronize unmigrated apps: staticfiles, messages
 > Â  Apply all migrations: admin, contenttypes, sessions, auth,
readDatabase
 > Synchronizing apps without migrations:
 > Â  Creating tables...
 > Â Â Â  Running deferred SQL...
 > Â  Installing custom SQL...
 > Running migrations:
 > Â  Rendering model states... DONE
 > Â  Applying readDatabase.0001_initial...Traceback (most recent
call last):
 > Â  File
 >
"/home/christoph_knapp/Bioinformatik/variantendatenbank_tool/manage.py",

 > line 10, in 
 > Â Â Â  execute_from_command_line(sys.argv)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py",

 > line 351, in execute_from_command_line
 > Â Â Â  utility.execute()
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py",

 > line 343, in execute
 > Â Â Â  self.fetch_command(subcommand).run_from_argv(self.argv)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py",

 > line 394, in run_from_argv
 > Â Â Â  self.execute(*args, **cmd_options)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py",

 > line 445, in execute
 > Â Â Â  output = self.handle(*args, **options)
 > Â  File
 >

"/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py",

 > line 222, in handle
 > Â Â Â  executor.migrate(targets, plan, fake=fake,
fake_initial=fake_initial)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py",

 > line 110, in migrate
 > Â Â Â  self.apply_migration(states[migration], migration,
fake=fake,
 > fake_initial=fake_initial)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py",

 > line 148, in apply_migration
 > Â Â Â  state = migration.apply(state, schema_editor)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/db/migrations/migration.py",

 > line 115, in apply
 > Â Â Â  operation.database_forwards(self.app_label,
schema_editor,
 > old_state, project_state)
 > Â  File
 >

"/usr/local/lib/python2.7/dist-packages/django/db/migrations/operations/models.py",

 > line 59, in database_forwards
 > Â Â Â  schema_editor.create_model(model)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/db/backends/base/schema.py",

 > line 286, in create_model
 > Â Â Â  self.execute(sql, params or None)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/db/backends/base/schema.py",

 > line 111, in execute
 > Â Â Â  cursor.execute(sql, params)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py",
 > line 79, in execute
 > Â Â Â  return super(CursorDebugWrapper, self).execute(sql,
params)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py",
 > line 64, in execute
 > Â Â Â  return self.cursor.execute(sql, params)
 > Â  File
"/usr/local/lib/python2.7/dist-packages/django/db/utils.py",
 > line 97, in __exit__
 > Â Â Â  six.reraise(dj_exc_type, dj_exc_value, traceback)
 > Â  File
 >
"/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py",
 > line 62, in execute
 > Â Â Â  return self.cursor.execute(sql)
 > django.db.utils.ProgrammingError: FEHLER:Â  Relation
„auth_group“
 > existiert bereits
 >
 > The last line contains a little bit of German which translates into
 > "Relation "auth_group" already exists". T

Re: Django admin add related object doesn't open popup window?

[Derek]

Disable the popup ... a suggestion was made in 
 https://code.djangoproject.com/ticket/9071 which is:

class ProductAdmin(ModelAdmin):

def get_form(self, request, obj=None, **kwargs):
"""
Don't allow adding new Product Categories
"""
form = super(ProductAdmin, self).get_form(request, obj, **kwargs)
form.base_fields['category'].widget.can_add_related = False
return form


On Thursday, 22 October 2015 16:48:14 UTC+2, j.coss...@gmail.com wrote:
>
> I already posted this question on Stackoverflow (
> http://stackoverflow.com/q/33189728/855050), but haven't received any 
> answers, just a comment by another user with the same issue. I am posting 
> here for added visibility. I think this is a bug in Django v1.8. I'll copy 
> the question's text here for convenience.
>
> The django-admin app is supposed to open a popup window when I try to 
> create a related object. For example, clicking the green plus button here:
>
> 
>
>
>
>
>
> Should bring a new pop-up window, where I can create a new related (in 
> this case Session) object. However, when I click the green plus button, the 
> object create opens up in the same window, instead of a pop-up window. This 
> is a problem, because if a user starts to create a primary object, then 
> half-way through, clicks the green plus, he will lose all the progress on 
> the primary object. This means that the green plus is unusable.
>
> I have no idea why this is happening. Any ideas of how I can diagnose 
> this? And fix it?
>
>
>
> Related: http://stackoverflow.com/q/29811544/855050. But he's using 
> Grappelli, which I am not. I am using the default django admin interface.
>
> I am using Django version 1.8.
>
> *PD:* In the meantime, is there a way to disable the popups? Right now 
> this feature is broken in my server and its affecting my users.
>
>

-- 
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/4ac78afe-afe8-4696-815d-23546ad743da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.