Re: Dropzone.js and images POST on new object

[James Schneider]

I wouldn't store binary data like an image in a session, especially if you
have a DB-backed session system.

I would instead use a separate model just for the images so that they can
be created on the fly by dropzone via an API call, and then you can save
the ID of the image object in the session (or update a hidden field in the
form) and later attach it to the object you are creating via the form by a
foreign key or one-to-one relationship when saving the form object.

There would still be other potential issues like the possibility of
orphaned images if a user uploads an image but then doesn't complete the
form. You may need some sort of nightly cleanup management command to run
to do something with the orphan images, like delete them.

Also, unless you know or manipulate the images to be small, make sure that
you don't store them in the database itself, use the file system. The DB is
a bad place for binary data blobs in most situations.

-James
Hello mates!
I tried dropzone.js on my app and everything worked fine. Now I want to use
it in a view that loads a form for tthe creation of a new object. The
dropzone where the user drop the images should load the images on the
server instantly and not when the user submit the form.

This approach is easy to do when the object is already in the model, for
example when I want to change the profile image of the user, but when the
object is not even in the database, how I can upload instantly the images?

I though that I could write a view to use with dropzone that get the images
and store them in the sessions. Than when the user submit the form, the
form object get the images from the session and save them in the new
object. Could be a good design pattern?

Thank you!

-- 
Karim N. Gorjux

-- 
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/CACeuRGXU0DynH%3D%2BbmGx8Ks_C7ZsyHAn8%3D7TsbRK6TyGTpckEbg%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%2Be%2BciX3PmfhkTop0EoyGfq5rdBUP9v2_xHBAmKWf8%3DrQTE%2BRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

cache.set(key, timeout=0)

[Thomas Güttler]

I want the cache timeout to be configurable:

 - N --> number of seconds
 - None --> cache for every
 - 0 --> do not cache at all.

I am not sure if timeout=0 really does what I want.

I could not find it explicitly in the docs: 
https://docs.djangoproject.com/en/1.7/topics/cache/#basic-usage

I don't want to put a lot of "if default_cache_timeout==0: " into my code.

It would be nice if django would support this. This would make my code simpler.

Does cache.set(key, timeout=0) do no caching at all?

If yes, shouldn't this be stated in the docs explicitly?

Regards,
  Thomas Güttler

--
Thomas Güttler
http://thomas-guettler.de/

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

Re: Tests and read-only database

[Avraham Serour]

you can tell django to use sqlite for tests, it will create an in memory
sqlite

if you need the data on the DB for the tests you can import when
initializing the tests, dump a part of the data and call it test data

On Tue, Feb 10, 2015 at 3:29 AM, Scot Hacker  wrote:

> My project access two databases, one of which is remote and read-only.
> When running tests, Django wants to create a test_ copy of that db on the
> remote host, but of course it lacks permission (I lack write access to the
> entire db host). So I'm blocked from running *any* tests, even ones that
> don't involve models for the remote data.
>
> I've come up with four possible solutions:
>
> 1) Tell Django's test runner to create the test version of that db
> locally, not on the remote host. However, the documentation
> 
> doesn't indicate a way to use the TEST: {} dictionary to specify an
> alternate host. This would be my preferred approach, but it doesn't seem
> possible.
>
> 2) Use this
> 
> module, which tells the test runner to treat the read-only db "as-is"
> rather than creating a copy of it. I don't like this because of the risk
> that the db might one day NOT be read-only (it's been discussed in our
> org). And  the module is 3 years old without updates.
>
> 3) Use this  technique, where
> the read-only db is pop()'d off the settings, making Django effectively
> forget it exists during testing (but then of course I can't test any code
> that involves those models). I'm currently doing this just to get tests
> back on the rails, but it's obviously very limiting.
>
> 4) Use this
> 
> technique, which alters the routers configuration during testing.
>
> Is there a preferred or recommended approach to this problem?
>
> 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/2d599e4b-d208-472f-9a62-fc9c187da1d1%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/CAFWa6tLbcpXps87WB9RsFyRmDLZf5F3eL-LwsHyni1duZxEnpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: use apache instead of server by default

[Thierry Granier]

peraps but i have no choice and i must use apache.
I don't understand the different docs tu use apache.

Help please
Thanks

Le dimanche 8 février 2015 23:20:31 UTC+1, Thierry Granier a écrit :
>
> Hello
>
> i have installed python3.4 and django1.7 on debian jessie.
>
> runserver works with mysql-connector and mysql databases.
>
> I'd like to use apache instead of this server.
> So i have installed via sysaptic the module libapache2-mod-wsgi
>
> why can't i install my website root in the document/root of apache?
> i don't understand the virtualhost and the directives associated.
>
> Thanks for your help
>
> T.
>

-- 
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/031aeba6-99e0-48a4-a74c-cc5d05f08052%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django: get profiles having auth.Group as foreign key

[itsjay040]

I have an model which uses auth.models Group as foreign key called 
Dashboard:-





class Dashboard(models.Model):
d_name = models.CharField(max_length=200)
d_description = models.CharField(max_length=200)
d_url = models.CharField(max_length=200)
d_status = models.CharField(max_length=200)
owner = models.ForeignKey(Group)

def __str__(self):return self.d_name



my views.py is:-





def custom_login(request):
if request.user.is_authenticated():
return HttpResponseRedirect('dashboards')
return login(request, 'login.html', authentication_form=LoginForm)

def custom_logout(request):
return logout(request, next_page='/')

def user(request):
context = {'user': user, 'groups': request.user.groups.all()}
return render_to_response('registration/dashboards.html', context, 
context_instance=RequestContext(request))



and here using this dashboards.html i want to display the dashboards by 
using the Group_name which i will get as a result of **group.name** :-





{% extends "base.html" %}
{% block content %}
{% if user.is_authenticated %}
Welcome, {{ request.user.get_username }}. 
{% else %}
Welcome, new user. Please log in.
{% endif %}


{% for group in groups %}

{{ group.name }} -

{{ dashboards.d_name }}{% if not forloop.last %},{% endif %}


{% endfor %}




{% endblock %}



here i have mentioned all the supporting information for my problem, please 
let me know if there are any solution.

-- 
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/7eab8d65-a83d-4faa-9ac8-fee369bf04a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django 1.7 migration generates wrong column name for foreign key to a one-to-one model

[Jack Peng]

I ran into this problem trying to run manage.py test. The error I get looks 
like this:


ALTER TABLE "quote_agentorderrejection" ADD CONSTRAINT 
"quote_agentor_agent_id_1388a6f8215473de_fk_user_agentprofile_id" FOREIGN 
KEY ("agent_id") REFERENCES "user_agentprofile" ("id") DEFERRABLE INITIALLY 
DEFERRED
Traceback (most recent call last):
File 
"/home/jack/Envs/envp1/lib/python3.4/site-packages/django/db/backends/utils.py",
 
line 66, in execute
return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: column "id" referenced in foreign key constraint 
does not exist


I realize this is similar to https://code.djangoproject.com/ticket/23415, 
which has been fixed. However, my case is a little different.


class AgentOrderRejection(models.Model):
agent = models.ForeignKey(AgentProfile)

But AgentProfile itself is a one-to-one model to the user model, so its 
primary key is user_id, not id.

user = models.OneToOneField(USER_MODEL, primary_key=True)

But django 1.7's migration incorrectly identifies id as the primary key and 
looks for it in the agentprofile model and fails. Does anyone have similar 
experiences? Thanks.

Jack



-- 
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/e3d2cdb7-4982-4de7-bd4c-60ca779187a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

JsonResponse and ajax function

[elcaiaimar]

Hello!

I've written a code to delete db registers and I want to call an ajax 
function when the delete is done.
At the moment, when I click my delete button I only receive a message: 
{"status":"True","product_id":p.id} or {"status":"False"} 
and this should be sent to the ajax function and I shoud have an alert 
saying to me: product has been removed.
I don't know why, probably there is something wrong in the relation of my 
JsonResponse and ajax function.

I put my code below. Does anybody know how can I fix this?
Thank you very much!

*template*:

 
  {% csrf_token %}
  
  Cerrar
  Eliminar
 

*views.py:*

if request.method=="POST":
if "product_id" in request.POST:
try:
id_producto = request.POST['product_id']
p = Pozo.objects.get(pk=id_producto)
mensaje = {"status":"True","product_id":p.id}
p.delete() # Elinamos objeto de la base de datos
return JsonResponse(mensaje)
except:
mensaje = {"status":"False"}
return JsonResponse(mensaje)



*Ajax.js:*/ Autor: @jqcaper
// Configuraciones Generales
var nombre_tabla = "#tabla_productos"; // id
var nombre_boton_eliminar = ".delete"; // Clase
var nombre_formulario_modal = "#frmEliminar"; //id
var nombre_ventana_modal = "#myModal"; // id
// Fin de configuraciones
$(document).on('ready',function(){
$(nombre_boton_eliminar).on('click',function(e){
e.preventDefault();
var Pid = $(this).attr('id');
var name = $(this).data('name');
$('#modal_idProducto').val(Pid);
$('#modal_name').text(name);
});
var options = {
success:function(response)
{
if(response.status=="True"){
alert("Eliminado!");
var idProd = response.product_id;
var elementos= $(nombre_tabla+' >tbody >tr').length;
if(elementos==1){
location.reload();
}else{
$('#tr'+idProd).remove();
$(nombre_ventana_modal).modal('hide');
}
}else{
alert("Hubo un error al eliminar!");
$(nombre_ventana_modal).modal('hide');
};
}
};
$(nombre_formulario_modal).ajaxForm(options);
});

-- 
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/c295d8a5-79bb-427b-be04-86dcb0d698e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

JsonResponse and Ajax function.

[elcaiaimar]

Hello!

I've written a code to delete db registers and I want to call an ajax 
function when the delete is done.
At the moment, when I click my delete button I only receive a message: 
{"status":"True","product_id":p.id} or {"status":"False"} 
and this should be sent to the ajax function and I shoud have an alert 
saying to me: product has been removed.
I don't know why, probably there is something wrong in the relation of my 
JsonResponse and ajax function.

I put my code below. Does anybody know how can I fix this?
Thank you very much!

*template*:

 
  {% csrf_token %}
  
  Cerrar
  Eliminar
 

*views.py:*

if request.method=="POST":
if "product_id" in request.POST:
try:
id_producto = request.POST['product_id']
p = Pozo.objects.get(pk=id_producto)
mensaje = {"status":"True","product_id":p.id}
p.delete() # Elinamos objeto de la base de datos
return JsonResponse(mensaje)
except:
mensaje = {"status":"False"}
return JsonResponse(mensaje)



*Ajax.js:*// Autor: @jqcaper
// Configuraciones Generales
var nombre_tabla = "#tabla_productos"; // id
var nombre_boton_eliminar = ".delete"; // Clase
var nombre_formulario_modal = "#frmEliminar"; //id
var nombre_ventana_modal = "#myModal"; // id
// Fin de configuraciones
$(document).on('ready',function(){
$(nombre_boton_eliminar).on('click',function(e){
e.preventDefault();
var Pid = $(this).attr('id');
var name = $(this).data('name');
$('#modal_idProducto').val(Pid);
$('#modal_name').text(name);
});
var options = {
success:function(response)
{
if(response.status=="True"){
alert("Eliminado!");
var idProd = response.product_id;
var elementos= $(nombre_tabla+' >tbody >tr').length;
if(elementos==1){
location.reload();
}else{
$('#tr'+idProd).remove();
$(nombre_ventana_modal).modal('hide');
}
}else{
alert("Hubo un error al eliminar!");
$(nombre_ventana_modal).modal('hide');
};
}
};
$(nombre_formulario_modal).ajaxForm(options);
});

-- 
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/66cfb1b0-e5e0-4393-8e87-2cde5a9f77c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Question about subdomains.

[Chen Xu]

Hi
I am using Django to build a website.

I saw some websites have www.ABC.com, support.ABC.com, and career.ABC.com.
I wonder how this is achieved. Are these 3 different apps in 1 project, or
3 different projects.

Thanks



-- 
⚡ Chen Xu ⚡

-- 
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/CACac-qbEVzrX4W-A2jFMoi5ogTFeptj65kLyH3_UkOQ%3Dw%2BvAWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about subdomains.

[Tom Christie]

> Are these 3 different apps in 1 project, or 3 different projects.

Either are possible. It depends on the application.

-- 
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/a4e4bca6-fbdb-4442-81e5-c52c6b6881f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Logging transaction statements?

[Erik Cederstrand]

Hi list,

I'm tracking down a bug in my app that shouldn't be happening with the 
transaction statements I added in my code. In my logging settings, I can set 
'django.db.backends' to DEBUG to log the queries (I'm using the postresql 
backend). I see 'SAVEPOINT' statements logged, but I also need 'BEGIN' and 
'COMMIT' so I can see when the transaction started and ended. How do I do that?

Thanks,
Erik

-- 
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/675FA187-3A66-4F3D-80CE-E6941C1050BC%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Logging transaction statements?

[Erik Cederstrand]

> Den 10/02/2015 kl. 17.15 skrev Erik Cederstrand :
> 
> Hi list,
> 
> I'm tracking down a bug in my app that shouldn't be happening with the 
> transaction statements I added in my code. In my logging settings, I can set 
> 'django.db.backends' to DEBUG to log the queries (I'm using the postresql 
> backend). I see 'SAVEPOINT' statements logged, but I also need 'BEGIN' and 
> 'COMMIT' so I can see when the transaction started and ended. How do I do 
> that?

Hmm, I'm beginning to think I don't understand Django transactions. I have the 
following two snippets, boiled down from my original code. The first one calls 
cache methods via helper functions, the other one calls the cache methods 
directly. If I run the code in parallel in two different processes, then the 
first example asserts almost instantly, while the second example survives 
several minutes. Can someone explain this?

import random
from django.db import transaction
from django.core.cache import cache

def get_val(key):
cache.get(key)

def set_val(key, val):
cache.add(key, val)

def del_val(key):
cache.delete(key)


# First example, fails
while True:
with transaction.atomic():
if not get_val('foo'):
print('no key found')
time.sleep(random.random())
if set_val('foo', 'bar'):
print('key added')
time.sleep(random.random())
else:
assert False
del_val('foo')
print('key deleted')
time.sleep(random.random())


# Second example, runs correctly
while True:
with transaction.atomic():
if not cache.get('foo'):
print('no key found')
time.sleep(random.random())
if cache.add('foo', 'bar'):
print('key added')
time.sleep(random.random())
else:
assert False
cache.delete('foo')
print('key deleted')
time.sleep(random.random())

Thanks,
Erik

-- 
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/5D7F4F83-FFEB-4658-AF81-B6B94576ADBA%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Logging transaction statements?

[Carl Meyer]

Hi Erik,

On 02/10/2015 10:28 AM, Erik Cederstrand wrote:
> Hmm, I'm beginning to think I don't understand Django transactions. I
> have the following two snippets, boiled down from my original code. The
> first one calls cache methods via helper functions, the other one calls
> the cache methods directly. If I run the code in parallel in two
> different processes, then the first example asserts almost instantly,
> while the second example survives several minutes. Can someone explain this?

I assume you're using the 'db' cache backend? Otherwise, it wouldn't
make sense to expect transactions to affect cache calls at all.

> import random
> from django.db import transaction
> from django.core.cache import cache
> 
> def get_val(key):
> cache.get(key)
> 
> def set_val(key, val):
> cache.add(key, val)
> 
> def del_val(key):
> cache.delete(key)
> 
> 
> # First example, fails
> while True:
> with transaction.atomic():
> if not get_val('foo'):
> print('no key found')
> time.sleep(random.random())
> if set_val('foo', 'bar'):
> print('key added')
> time.sleep(random.random())
> else:
> assert False
> del_val('foo')
> print('key deleted')
> time.sleep(random.random())
> 
> 
> # Second example, runs correctly
> while True:
> with transaction.atomic():
> if not cache.get('foo'):
> print('no key found')
> time.sleep(random.random())
> if cache.add('foo', 'bar'):
> print('key added')
> time.sleep(random.random())
> else:
> assert False
> cache.delete('foo')
> print('key deleted')
> time.sleep(random.random())

The difference between the snippets is that you are doing a conditional
branch based on the return value of the cache add, but your set_val
helper method always returns None, it doesn't return the return value of
cache.add().

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/54DA4136.8020105%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: django 1.7 migration generates wrong column name for foreign key to a one-to-one model

[Dhelbegor]

you using primary_key in one OnetoOneField,  please create other Field id = 
AutoField(primary_key=True)

ex:
class AgentOrderRejection(models.Model):
id_agent = models.AutoField(primary_key=True)
agent = models.ForeignKey(AgentProfile)
user = models.OneToOneField(USER_MODEL)


or use this:

http://stackoverflow.com/questions/26188997/django-model-onetoonefield-without-creating-additional-id-database-column

sorry for my bad english

Att;

Adailton do nascimento

-- 
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/5c8ac0ed-299e-4311-868f-f4aaa863a38e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tests and read-only database

[Scot Hacker]

On Tuesday, February 10, 2015 at 12:55:57 AM UTC-8, Avraham Serour wrote:
>
> you can tell django to use sqlite for tests, it will create an in memory 
> sqlite
>

Thanks Avraham. Having a bit of trouble finding specifics on this in the 
documentation, but this works neatly:

if 'test' in sys.argv or 'test_coverage' in sys.argv:  # Covers regular 
testing and django-coverage
DATABASES['default']['ENGINE'] = 'django.db.backends.sqlite3'
DATABASES['tmi']['ENGINE'] = 'django.db.backends.sqlite3' 

Nice speed improvement with those in-memory dbs, too! 

./s

-- 
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/71da6c8c-69ce-4a76-96b5-624be72771cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logging transaction statements?

[Erik Cederstrand]

Hi Carl,

> Den 10/02/2015 kl. 18.34 skrev Carl Meyer  >:
> 
> I assume you're using the 'db' cache backend? Otherwise, it wouldn't
> make sense to expect transactions to affect cache calls at all.

Yes, I'm using the db backend.

> The difference between the snippets is that you are doing a conditional
> branch based on the return value of the cache add, but your set_val
> helper method always returns None, it doesn't return the return value of
> cache.add().

Wow, *that* was embarrassing :-) You see what you want to see, I guess...

I'm still having issues with this, though. I reduced my own code to the 
following. The intent of the code is to use the cache to implement 
multiprocess/multiserver locking:

from django.db import transaction
from django.core.cache import cache

class CacheError(Exception):
pass

cache.delete('foo')
while True:
print('Trying to cache foo')
try:
with transaction.atomic():
if cache.get('foo'):
raise CacheError()
print('adding foo to cache')
assert cache.add(key='foo', value='bar')
print('foo cached')
time.sleep(random.random())
with transaction.atomic():
if cache.get('foo'):
cache.delete('foo')
except CacheError:
print('Failed to cache foo')
time.sleep(random.random())

Running this in parallel in two processes on the same machine returns this 
after a while:

Process A:
Trying to cache foo
2015-02-10 21:02:25,781 DEBUG(0.001) SELECT cache_key, value, expires FROM 
"dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
adding foo to cache
2015-02-10 21:02:25,782 DEBUG(0.000) SELECT COUNT(*) FROM "dispatch_cache"; 
args=None
2015-02-10 21:02:25,782 DEBUG(0.000) SAVEPOINT "s140735261451008_x1"; 
args=None
2015-02-10 21:02:25,783 DEBUG(0.000) SELECT cache_key, expires FROM 
"dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
2015-02-10 21:02:25,784 DEBUG(0.000) INSERT INTO "dispatch_cache" 
(cache_key, value, expires) VALUES ('foo', 'gASVBwCMA2JhcpQu', 
'-12-31 23:59:59'); args=['foo', 'gASVBwCMA2JhcpQu', '-12-31 
23:59:59']
2015-02-10 21:02:25,784 DEBUG(0.000) RELEASE SAVEPOINT 
"s140735261451008_x1"; args=None
foo cached
2015-02-10 21:02:26,771 DEBUG(0.000) SELECT cache_key, value, expires FROM 
"dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
2015-02-10 21:02:26,772 DEBUG(0.000) DELETE FROM "dispatch_cache" WHERE 
cache_key = 'foo'; args=['foo']


Process B:
Trying to cache foo
2015-02-10 21:02:25,782 DEBUG(0.000) SELECT cache_key, value, expires FROM 
"dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
adding foo to cache
2015-02-10 21:02:25,783 DEBUG(0.000) SELECT COUNT(*) FROM "dispatch_cache"; 
args=None
2015-02-10 21:02:25,784 DEBUG(0.000) SAVEPOINT "s140735261451008_x1"; 
args=None
2015-02-10 21:02:25,784 DEBUG(0.000) SELECT cache_key, expires FROM 
"dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
2015-02-10 21:02:25,791 DEBUG(0.007) INSERT INTO "dispatch_cache" 
(cache_key, value, expires) VALUES ('foo', 'gASVBwCMA2JhcpQu', 
'-12-31 23:59:59'); args=['foo', 'gASVBwCMA2JhcpQu', '-12-31 
23:59:59']
2015-02-10 21:02:25,792 DEBUG(0.000) ROLLBACK TO SAVEPOINT 
"s140735261451008_x1"; args=None
Traceback (most recent call last):
  File "tmp.py", line 30, in 
assert cache.add(key='foo', value='bar')
AssertionError


I don't see how this is possible when I'm using transaction.atomic().


Thanks,
Erik

-- 
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/FD568626-E3C3-4026-9617-3EDB24F037D8%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Dropzone.js and images POST on new object

[Karim]

On Tue, Feb 10, 2015 at 7:25 PM, James Schneider 
wrote:

> I wouldn't store binary data like an image in a session, especially if you
> have a DB-backed session system.
>
> ​[]
>
> ​Thank you James.​


-- 
Karim N. Gorjux

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

Re: Logging transaction statements?

[Carl Meyer]

On 02/10/2015 01:27 PM, Erik Cederstrand wrote:
>> Den 10/02/2015 kl. 18.34 skrev Carl Meyer > >:
>>
>> I assume you're using the 'db' cache backend? Otherwise, it wouldn't
>> make sense to expect transactions to affect cache calls at all.
> 
> Yes, I'm using the db backend.
> 
>> The difference between the snippets is that you are doing a conditional
>> branch based on the return value of the cache add, but your set_val
>> helper method always returns None, it doesn't return the return value of
>> cache.add().
> 
> Wow, *that* was embarrassing :-) You see what you want to see, I guess...
> 
> I'm still having issues with this, though. I reduced my own code to the
> following. The intent of the code is to use the cache to implement
> multiprocess/multiserver locking:
> 
> from django.db import transaction
> from django.core.cache import cache
> 
> class CacheError(Exception):
> pass
> 
> cache.delete('foo')
> while True:
> print('Trying to cache foo')
> try:
> with transaction.atomic():
> if cache.get('foo'):
> raise CacheError()
> print('adding foo to cache')
> assert cache.add(key='foo', value='bar')
> print('foo cached')
> time.sleep(random.random())
> with transaction.atomic():
> if cache.get('foo'):
> cache.delete('foo')
> except CacheError:
> print('Failed to cache foo')
> time.sleep(random.random())
> 
> 
> Running this in parallel in two processes on the same machine returns
> this after a while:
> 
> Process A:
> Trying to cache foo
> 2015-02-10 21:02:25,781 DEBUG(0.001) SELECT cache_key, value,
> expires FROM "dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
> adding foo to cache
> 2015-02-10 21:02:25,782 DEBUG(0.000) SELECT COUNT(*) FROM
> "dispatch_cache"; args=None
> 2015-02-10 21:02:25,782 DEBUG(0.000) SAVEPOINT
> "s140735261451008_x1"; args=None
> 2015-02-10 21:02:25,783 DEBUG(0.000) SELECT cache_key, expires FROM
> "dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
> 2015-02-10 21:02:25,784 DEBUG(0.000) INSERT INTO "dispatch_cache"
> (cache_key, value, expires) VALUES ('foo', 'gASVBwCMA2JhcpQu',
> '-12-31 23:59:59'); args=['foo', 'gASVBwCMA2JhcpQu',
> '-12-31 23:59:59']
> 2015-02-10 21:02:25,784 DEBUG(0.000) RELEASE SAVEPOINT
> "s140735261451008_x1"; args=None
> foo cached
> 2015-02-10 21:02:26,771 DEBUG(0.000) SELECT cache_key, value,
> expires FROM "dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
> 2015-02-10 21:02:26,772 DEBUG(0.000) DELETE FROM "dispatch_cache"
> WHERE cache_key = 'foo'; args=['foo']
> 
> 
> Process B:
> Trying to cache foo
> 2015-02-10 21:02:25,782 DEBUG(0.000) SELECT cache_key, value,
> expires FROM "dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
> adding foo to cache
> 2015-02-10 21:02:25,783 DEBUG(0.000) SELECT COUNT(*) FROM
> "dispatch_cache"; args=None
> 2015-02-10 21:02:25,784 DEBUG(0.000) SAVEPOINT
> "s140735261451008_x1"; args=None
> 2015-02-10 21:02:25,784 DEBUG(0.000) SELECT cache_key, expires FROM
> "dispatch_cache" WHERE cache_key = 'foo'; args=['foo']
> 2015-02-10 21:02:25,791 DEBUG(0.007) INSERT INTO "dispatch_cache"
> (cache_key, value, expires) VALUES ('foo', 'gASVBwCMA2JhcpQu',
> '-12-31 23:59:59'); args=['foo', 'gASVBwCMA2JhcpQu',
> '-12-31 23:59:59']
> 2015-02-10 21:02:25,792 DEBUG(0.000) ROLLBACK TO SAVEPOINT
> "s140735261451008_x1"; args=None
> Traceback (most recent call last):
>   File "tmp.py", line 30, in 
> assert cache.add(key='foo', value='bar')
> AssertionError
> 
> 
> I don't see how this is possible when I'm using transaction.atomic().

I believe you're running into the difference between the transaction
isolation levels REPEATABLE READ vs READ COMMITTED. The former is the
default for MySQL, the latter for PostgreSQL.

In REPEATABLE READ isolation level, once you enter a transaction your
view of the world will never change, except due to your own actions,
until the end of that transaction. In READ COMMITTED, your changes
within the transaction will still all be committed or rolled back as an
atomic unit, but your view of the rest of the world can change
mid-transaction, if another transaction commits in the meantime.

I think the results you are seeing are explainable if you are using READ
COMMITTED.

Either one of these levels can cause people trouble if they don't
understand the difference and know which one they are using. (I often
see MySQL users confused why a long-running shell process never seems to
see any database updates made by a different process.) You have to
decide which one is more appropriate for your application, and code
accordingly.

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 djang

Re: Logging transaction statements?

[Carl Meyer]

On 02/10/2015 02:46 PM, Carl Meyer wrote:
> On 02/10/2015 01:27 PM, Erik Cederstrand wrote:
>>> Den 10/02/2015 kl. 18.34 skrev Carl Meyer >> >:
>>>
>>> I assume you're using the 'db' cache backend? Otherwise, it wouldn't
>>> make sense to expect transactions to affect cache calls at all.
>>
>> Yes, I'm using the db backend.
>>
>>> The difference between the snippets is that you are doing a conditional
>>> branch based on the return value of the cache add, but your set_val
>>> helper method always returns None, it doesn't return the return value of
>>> cache.add().
>>
>> Wow, *that* was embarrassing :-) You see what you want to see, I guess...
>>
>> I'm still having issues with this, though. I reduced my own code to the
>> following. The intent of the code is to use the cache to implement
>> multiprocess/multiserver locking:
>>
>> from django.db import transaction
>> from django.core.cache import cache
>>
>> class CacheError(Exception):
>> pass
>>
>> cache.delete('foo')
>> while True:
>> print('Trying to cache foo')
>> try:
>> with transaction.atomic():
>> if cache.get('foo'):
>> raise CacheError()
>> print('adding foo to cache')
>> assert cache.add(key='foo', value='bar')
>> print('foo cached')
>> time.sleep(random.random())
>> with transaction.atomic():
>> if cache.get('foo'):
>> cache.delete('foo')
>> except CacheError:
>> print('Failed to cache foo')
>> time.sleep(random.random())

You might find it useful to look at the implementation of Django's
QuerySet.get_or_create() method, if you want to see how to (mostly)
safely implement a get-or-create pattern like this without race
conditions under READ COMMITTED isolation level.

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/54DA7D14.9030208%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Logging transaction statements?

[Erik Cederstrand]

Den 10/02/2015 kl. 21.27 skrev Erik Cederstrand :
> 
> Running this in parallel in two processes on the same machine returns this 
> after a while:
> 
> Process A:
> [...]
> 
> Process B:
> [...]
> Traceback (most recent call last):
>   File "tmp.py", line 30, in 
> assert cache.add(key='foo', value='bar')
> AssertionError
> 
> 
> I don't see how this is possible when I'm using transaction.atomic().

Phew. This situation is actually possible since "Read Committed" is the default 
isolation level in PostgreSQL, which means that non-repeatable reads are 
possible within a transaction.

My code relies on isolation level "Serializable" for a cache.get() followed by 
cache.add() to be reliable, but Django uses the default from PostgreSQL.

The isolation level is supposed to be configurable with the 'isolation_level' 
setting in OPTIONS 
(https://docs.djangoproject.com/en/1.7/ref/databases/#isolation-level). Except 
it doesn't work because 
django/db/backends/postgresql_psycopg2/base.py::_set_isolation_level() is never 
called anywhere, AFAICS.

I tried disabling autocommit (the docs are wrong BTW, 
https://docs.djangoproject.com/en/1.7/ref/databases/#autocommit-mode says to 
put it in OPTIONS, but django/db/backends/__init__.py (line 123) looks at 
settings_dict['AUTOCOMMIT'], not in OPTIONS) and hacking 
postgresql_psycopg2/base.py::_set_autocommit() to call _set_isolation_level(), 
but now process A blocks process B entirely, even when process A is outside the 
atomic() context manager.

Has anyone got isolation_level "Serializable" to work in Django 1.7?


Thanks,
Erik

-- 
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/12300B76-606A-4977-A402-990D562C7F77%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Logging transaction statements?

[Carl Meyer]

Hi Erik,

On 02/10/2015 03:30 PM, Erik Cederstrand wrote:
> Den 10/02/2015 kl. 21.27 skrev Erik Cederstrand
> :
>> 
>> Running this in parallel in two processes on the same machine
>> returns this after a while:
>> 
>> Process A: [...]
>> 
>> Process B: [...] Traceback (most recent call last): File "tmp.py",
>> line 30, in  assert cache.add(key='foo', value='bar') 
>> AssertionError
>> 
>> 
>> I don't see how this is possible when I'm using
>> transaction.atomic().
> 
> Phew. This situation is actually possible since "Read Committed" is
> the default isolation level in PostgreSQL, which means that
> non-repeatable reads are possible within a transaction.

Yes, that's what I said :-)

> My code relies on isolation level "Serializable" for a cache.get()
> followed by cache.add() to be reliable, but Django uses the default
> from PostgreSQL.

I don't think you need full Serializable, Repeatable Read should be
sufficient. Serializable is dangerous, has a tendency to cause deadlocks
(as I think you've discovered). Even with Repeatable Read, you'll need
be a bit careful about any long-running processes that might hold open a
transaction.

> The isolation level is supposed to be configurable with the
> 'isolation_level' setting in OPTIONS
> (https://docs.djangoproject.com/en/1.7/ref/databases/#isolation-level).
> Except it doesn't work because
> django/db/backends/postgresql_psycopg2/base.py::_set_isolation_level()
> is never called anywhere, AFAICS.

But `self.connection.set_isolation_level()` is called in
`_set_autocommit()`, and that should be sufficient. (The
`_set_isolation_level()` method is dead code in 1.7 and has since been
removed, but what really matters is that
`self.connection.set_isolation_level()` is called.)

> I tried disabling autocommit (the docs are wrong BTW,
> https://docs.djangoproject.com/en/1.7/ref/databases/#autocommit-mode
> says to put it in OPTIONS, but django/db/backends/__init__.py (line
> 123) looks at settings_dict['AUTOCOMMIT'], not in OPTIONS)

OPTIONS['autocommit'] has been ignored since Django 1.6, as the docs you
linked clearly state: "This configuration is ignored and can be safely
removed."

You're looking for
https://docs.djangoproject.com/en/1.7/ref/settings/#autocommit instead.

(It would be good for the former to have a link to the latter, though.)

 and
> hacking postgresql_psycopg2/base.py::_set_autocommit() to call
> _set_isolation_level(), but now process A blocks process B entirely,
> even when process A is outside the atomic() context manager.
> 
> Has anyone got isolation_level "Serializable" to work in Django 1.7?

I strongly recommend against using the Serializable isolation level, or
turning off autocommit mode. The transaction.atomic() API will not work
correctly or predictably with autocommit turned off. See
https://docs.djangoproject.com/en/1.7/topics/db/transactions/#deactivate-transaction-management

You could switch to Repeatable Read (but leave AUTOCOMMIT on). Or (what
I would probably do) you could leave the isolation level at the default
(since it's the default for Django, some parts of Django, such as
QuerySet.get_or_create(), may not work correctly under a different
isolation level) and simply update your locking logic to guard against
that race condition (if the add fails, assume that another process has
grabbed the lock in the interim).

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/54DA8A07.9020704%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Logging transaction statements?

[Erik Cederstrand]

> Den 10/02/2015 kl. 23.45 skrev Carl Meyer :
> 
> Yes, that's what I said :-)

Thanks for the great explanations; I didn't see your previous answer before 
posting my latest reply, hence the duplicate explanations :-)
> 
>> My code relies on isolation level "Serializable" for a cache.get()
>> followed by cache.add() to be reliable, but Django uses the default
>> from PostgreSQL.
> 
> I don't think you need full Serializable, Repeatable Read should be
> sufficient. Serializable is dangerous, has a tendency to cause deadlocks
> (as I think you've discovered). Even with Repeatable Read, you'll need
> be a bit careful about any long-running processes that might hold open a
> transaction.

I was thinking Seralizable is needed since cache.get() is a query that could 
result in a phantom read. But since I have multiple long-running management 
jobs and incoming changes from a REST API, I also think I'll bee too vulnerable 
to deadlocks if I change the isolation level.

> But `self.connection.set_isolation_level()` is called in
> `_set_autocommit()`, and that should be sufficient. (The
> `_set_isolation_level()` method is dead code in 1.7 and has since been
> removed, but what really matters is that
> `self.connection.set_isolation_level()` is called.)

It's only called if self.psycopg2_version < (2, 4, 2), at least in the file I'm 
looking at. My version is 2.5.2.

> OPTIONS['autocommit'] has been ignored since Django 1.6, as the docs you
> linked clearly state: "This configuration is ignored and can be safely
> removed."
> 
> You're looking for
> https://docs.djangoproject.com/en/1.7/ref/settings/#autocommit instead.

Right you are :-) I should get some sleep.

> You could switch to Repeatable Read (but leave AUTOCOMMIT on). Or (what
> I would probably do) you could leave the isolation level at the default
> (since it's the default for Django, some parts of Django, such as
> QuerySet.get_or_create(), may not work correctly under a different
> isolation level) and simply update your locking logic to guard against
> that race condition (if the add fails, assume that another process has
> grabbed the lock in the interim).

Yeah, I think I'll do just that. My production code is a bit more complicated 
since it relies on two cache.get()'s before the cache.add(), but that will 
probably just have to go away.

Thanks again for you excellent help,
Erik

-- 
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/C42D1493-F3D4-416E-A6A9-AA78BB589F78%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Logging transaction statements?

[Carl Meyer]

On 02/10/2015 04:03 PM, Erik Cederstrand wrote:
>> But `self.connection.set_isolation_level()` is called in 
>> `_set_autocommit()`, and that should be sufficient. (The 
>> `_set_isolation_level()` method is dead code in 1.7 and has since
>> been removed, but what really matters is that 
>> `self.connection.set_isolation_level()` is called.)
> 
> It's only called if self.psycopg2_version < (2, 4, 2), at least in
> the file I'm looking at. My version is 2.5.2.

You're totally right. That's a bug. Thanks for catching it! I've filed
https://code.djangoproject.com/ticket/24318

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/54DA969C.7040509%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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

[Russell Keith-Magee]

Hi Thomas,

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

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

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

Yours
Russ Magee %-)

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

> I want the cache timeout to be configurable:
>
>  - N --> number of seconds
>  - None --> cache for every
>  - 0 --> do not cache at all.
>
> I am not sure if timeout=0 really does what I want.
>
> I could not find it explicitly in the docs: https://docs.djangoproject.
> com/en/1.7/topics/cache/#basic-usage
>
> I don't want to put a lot of "if default_cache_timeout==0: " into my
> code.
>
> It would be nice if django would support this. This would make my code
> simpler.
>
> Does cache.set(key, timeout=0) do no caching at all?
>
> If yes, shouldn't this be stated in the docs explicitly?
>
> Regards,
>   Thomas Güttler
>
> --
> Thomas Güttler
> http://thomas-guettler.de/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/54D9C6A3.9030506%40tbz-pariv.de.
> For more options, visit https://groups.google.com/d/optout.
>

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

Registering a stand-alone test app

[Nicole Harris]

Hi All,

I have an app in my root folder named 'bdd'.  It contains an (empty) 
models.py as well as some files for running behave 
 tests.
I have added this app to INSTALLED_APPS in my settings.py so that I can run 
the tests with the Django Behave 
 test runner.

When I deploy my application to Heroku, I get the following error: 
*The app module  has multiple filesystem 
locations (['./bdd', './bdd', '/app/bdd']); you must configure this app 
with an AppConfig subclass with a 'path' class attribute.*

Interestingly, this does not happen locally, or on my CI server.  

I am running 1.7, so my best guess is that this has something to do with 
https://docs.djangoproject.com/en/1.7/releases/1.7/#app-registry-consistency, 
but I'm having some trouble working out what the problem is.

I do *not* have another app or folder called "app" so, I can't make any 
sense of the '/app/bdd' line in the error message.

What's going on here?  Is it possible that my 'bdd' app is conflicting with 
another package?

Thanks in advance :D
Nicole


-- 
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/6db47a08-fdb3-4f8b-87ee-de3a409fdee9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Registering a stand-alone test app

[Avraham Serour]

This could be an issue with your pythonpath , it looks like the ./app
folder is being added twice to the path, so the import complains it found a
module with this name in multiple locations
On Feb 11, 2015 8:07 AM, "Nicole Harris" 
wrote:

> Hi All,
>
> I have an app in my root folder named 'bdd'.  It contains an (empty)
> models.py as well as some files for running behave
>  tests.
> I have added this app to INSTALLED_APPS in my settings.py so that I can
> run the tests with the Django Behave
>  test runner.
>
> When I deploy my application to Heroku, I get the following error:
> *The app module  has multiple filesystem
> locations (['./bdd', './bdd', '/app/bdd']); you must configure this app
> with an AppConfig subclass with a 'path' class attribute.*
>
> Interestingly, this does not happen locally, or on my CI server.
>
> I am running 1.7, so my best guess is that this has something to do with
> https://docs.djangoproject.com/en/1.7/releases/1.7/#app-registry-consistency,
> but I'm having some trouble working out what the problem is.
>
> I do *not* have another app or folder called "app" so, I can't make any
> sense of the '/app/bdd' line in the error message.
>
> What's going on here?  Is it possible that my 'bdd' app is conflicting
> with another package?
>
> Thanks in advance :D
> Nicole
>
>
>  --
> 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/6db47a08-fdb3-4f8b-87ee-de3a409fdee9%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/CAFWa6tJQduRYEiP81p3EJ27uAoPp0NOOzVDUBxpptF2f3sBODQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.