Re: Using the backend database to secure a page on the frontend

[Philip Mountifield]

If you want to use the existing permission system, I think you'll find 
this is what you need: 
https://docs.djangoproject.com/en/1.4/topics/auth/#the-permission-required-decorator


You could add some extra permissions to your models too if you need 
them: https://docs.djangoproject.com/en/1.4/ref/models/options/#permissions


Kind regards
Phil

On 30/03/2012 10:28, vanderkerkoff wrote:

Hello there

I"m sure this question has been answered before but I just can't find
it, apologies.

We've got a django 1.1.2 site and I need to secure some sections of
the frontend, and use the users and groups model in the backend as the
database to provide authentication.

I really don't know where to start to be honest.

Any links to examples would be great.

What would be really great is if there's a way in the urls.py file to
do something like this.

from django.contrib.auth.models import *
urlpatterns += patterns('django.auth.authenticate',
(r'^specificurl$',")
)

If I get it working on specific URLS first, I can then start to work
out how to incorporate the login section into parts of the app.  So
people could tick a page say as restricted, and then people would have
to login to see the page.

Any tips or links off to documentation would be really helpful.

Thanks




--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Using the backend database to secure a page on the frontend

[Philip Mountifield]

Looks like an issue with the location of the templete folder, your 
TEMPLATE_LOADERS setting or TEMPLATE_DIRS if you put your templates 
somewhere else.


Regards
Phil

On 30/03/2012 12:09, vanderkerkoff wrote:

Thanks for getting back to me Phillip.

I'm using that page as a guide, and i've got a pages application that
has a registration_required boolean field setup.

In my urls file I've got this

(r'^login/$', 'django.contrib.auth.views.login'),

In my page view I'm doing this

print pg.registration_required
print request.user.is_authenticated()
if pg.registration_required and not request.user.is_authenticated():
   return HttpResponseRedirect('/login/?next=%s' % request.path)

I've setup the auth middleware and pg is the page.

I can see that pg.registration_required is true, and that
request.user.is_authenticated() is false, so the code is trying to
send me to the login page.

The docs say to create registration/login.html as that is the default.

I've created a folder called registration in my templates folder, and
a page called login.html in that folder, but the site is still
throwing me a template not found error

Request Method: GET
Request URL:http://127.0.0.1:8000/login/?next=/helpline2/
Django Version: 1.3 beta 1 SVN-15046
Exception Type: TemplateDoesNotExist
Exception Value:registration/login.html

I must be doing something dull, anyone got any ideas?





On Mar 30, 11:02 am, Philip Mountifield
wrote:

If you want to use the existing permission system, I think you'll find
this is what you 
need:https://docs.djangoproject.com/en/1.4/topics/auth/#the-permission-req...

You could add some extra permissions to your models too if you need
them:https://docs.djangoproject.com/en/1.4/ref/models/options/#permissions

Kind regards
Phil

On 30/03/2012 10:28, vanderkerkoff wrote:










Hello there
I"m sure this question has been answered before but I just can't find
it, apologies.
We've got a django 1.1.2 site and I need to secure some sections of
the frontend, and use the users and groups model in the backend as the
database to provide authentication.
I really don't know where to start to be honest.
Any links to examples would be great.
What would be really great is if there's a way in the urls.py file to
do something like this.
from django.contrib.auth.models import *
urlpatterns += patterns('django.auth.authenticate',
 (r'^specificurl$',")
)
If I get it working on specific URLS first, I can then start to work
out how to incorporate the login section into parts of the app.  So
people could tick a page say as restricted, and then people would have
to login to see the page.
Any tips or links off to documentation would be really helpful.
Thanks

--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.netwww.formac.netwww.telgas.net



--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Dynamically generated models using exec. Is it too custly?

[Philip Mountifield]

Did you know that you can use the type function to dynamiclly generate a 
class definition?


See http://docs.python.org/library/functions.html?highlight=type#type

From the example:


 class  X(object):

... a  =  1

Is exactly the same as doing...


 X  =  type('X',  (object,),  dict(a=1))


No exec required...

Regards
Phil


On 16/04/2012 17:19, Arruda wrote:

I'm doing something like this to generate some models dynamically:

SIMILAR_MODELS_TEMPLATE=
"""
@some_decorator
class %(PREFIX)sModel (Some_Abs_model):
\"""%(DESCRIPTION)s
\"""
pass
"""


then I have a factory:

def similar_models_factory(prefix,description):
 format_dict = {
  'PREFIX' : prefix,
  'DESCRIPTION' : description,
 }
 cls_name = "%sModel" % prefix
 cls_source = SIMILAR_MODELS_TEMPLATE % format_dict

 exec(cls_source)
 new_cls = locals().get(cls_name)
 return new_cls


And finally I have in the models.py:

from my_factories import similar_models_factory

SIMILAR_MODELS_LIST =(
{'prefix': 'Foo', 'desc' : 'Foo model and etc..',},
{'prefix': 'Bars', 'desc' : 'Bars model and etc..',},
.
)

for smodel in SIMILAR_MODELS_LIST:
cls = similar_models_factory(smodels['prefix'], smodels['desc'])
vars()[cls.__name__] = cls


And this gives my just what I want, but I read somewhere that if you do:

exec ""

It would be too costly, and I would like to know if this would have 
some heavy load in my project(and if please, how can I calculate this, 
to compare?)

Thanks!
--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/64JCLnsIFu0J.

To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Dynamically generated models using exec. Is it too custly?

[Philip Mountifield]

Are you changing the definition of the function each time, or just 
effectively making duplicates of some common function under different names?


You can do things like this:

def make_funct(blah):
def inner():
print blah

return inner

Then make a few of them with different names and pre-assigned config via 
the parameters:


f1 = make_funct('Hello World!')
f2 = make_funct('Foo')

And call 'em (with no parameters):

f1()=>prints Hello World!
f2()=>prints Foo

Perhaps that's not what you're looking for though?

In terms of performance, I suggest trying out both approaches and 
measuring the time taken to do it a few hundred or thousand times and 
compare.


Regards
Phil


On 16/04/2012 17:55, Arruda wrote:

Hummm, I see, thanks for that, I didn't know about type.
And is there a way to generate functions too?(I was also doing it 
using exec).


And do you have any idea of how can I see the difference in 
performance when using one or the other?

Thanks.

Em segunda-feira, 16 de abril de 2012 13h45min58s UTC-3, Jefferson 
Heard escreveu:


Check https://github.com/JeffHeard/ga_dynamic_models
<https://github.com/JeffHeard/ga_dynamic_models>.  It may be
similar to what you're looking for.  Even if you don't want the
code, you can see a way of dynamically generating models.

On Mon, Apr 16, 2012 at 12:40 PM, Philip Mountifield
mailto:pmountifi...@formac.net>> wrote:

Did you know that you can use the type function to dynamiclly
generate a class definition?

See
http://docs.python.org/library/functions.html?highlight=type#type
<http://docs.python.org/library/functions.html?highlight=type#type>

From the example:

>>>  class  X(object):
... a  =  1

Is exactly the same as doing...

>>>  X  =  type('X',  (object,),  dict(a=1))

No exec required...

Regards
Phil



On 16/04/2012 17:19, Arruda wrote:

I'm doing something like this to generate some
models dynamically:

SIMILAR_MODELS_TEMPLATE=
"""
@some_decorator
class %(PREFIX)sModel (Some_Abs_model):
\"""%(DESCRIPTION)s
\"""
pass
"""


then I have a factory:

def similar_models_factory(prefix,description):
 format_dict = {
  'PREFIX' : prefix,
  'DESCRIPTION' : description,
 }
 cls_name = "%sModel" % prefix
 cls_source = SIMILAR_MODELS_TEMPLATE % format_dict

 exec(cls_source)
 new_cls = locals().get(cls_name)
 return new_cls


And finally I have in the models.py:

from my_factories import similar_models_factory

SIMILAR_MODELS_LIST =(
{'prefix': 'Foo', 'desc' : 'Foo model and etc..',},
{'prefix': 'Bars', 'desc' : 'Bars model and etc..',},
.
)

for smodel in SIMILAR_MODELS_LIST:
cls = similar_models_factory(smodels['prefix'],
smodels['desc'])
vars()[cls.__name__] = cls


And this gives my just what I want, but I read somewhere that
if you do:

exec ""

It would be too costly, and I would like to know if this
would have some heavy load in my project(and if please, how
can I calculate this, to compare?)
Thanks!
-- 
You received this message because you are subscribed to the

Google Groups "Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/64JCLnsIFu0J
<https://groups.google.com/d/msg/django-users/-/64JCLnsIFu0J>.
To post to this group, send email to
django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
<http://groups.google.com/group/django-users?hl=en>.



-- 


Philip Mountifield
Formac Electronics Ltd
tel+44 (0) 1225 837333
fax+44 (0) 1225 430995

pmountifi...@formac.net  <mailto:pmountifi...@formac.net>
www.formac.net  <http://www.formac.net>
 

Re: Dynamically generated models using exec. Is it too custly?

[Philip Mountifield]

You probably want the profile module from the standard library. This 
will tell you all sorts of useful things about how much time functions 
are taking and how many times they are called etc...


http://docs.python.org/library/profile.html#module-profile

Regards
Phil

On 17/04/2012 13:48, Arruda wrote:
yes, I see, but how can I measure this? Do you know the function that 
is used?

Thanks for the help.

Em terça-feira, 17 de abril de 2012 05h39min24s UTC-3, Philip escreveu:

Are you changing the definition of the function each time, or just
effectively making duplicates of some common function under
different names?

You can do things like this:

def make_funct(blah):
def inner():
print blah

return inner

Then make a few of them with different names and pre-assigned
config via the parameters:

f1 = make_funct('Hello World!')
f2 = make_funct('Foo')

And call 'em (with no parameters):

f1()=>prints Hello World!
f2()=>prints Foo

Perhaps that's not what you're looking for though?

In terms of performance, I suggest trying out both approaches and
measuring the time taken to do it a few hundred or thousand times
and compare.

Regards
Phil


On 16/04/2012 17:55, Arruda wrote:

Hummm, I see, thanks for that, I didn't know about type.
And is there a way to generate functions too?(I was also doing it
using exec).

And do you have any idea of how can I see the difference in
performance when using one or the other?
Thanks.

Em segunda-feira, 16 de abril de 2012 13h45min58s UTC-3,
Jefferson Heard escreveu:

Check https://github.com/JeffHeard/ga_dynamic_models
<https://github.com/JeffHeard/ga_dynamic_models>.  It may be
similar to what you're looking for.  Even if you don't want
the code, you can see a way of dynamically generating models.

On Mon, Apr 16, 2012 at 12:40 PM, Philip Mountifield
mailto:pmountifi...@formac.net>> wrote:

Did you know that you can use the type function to
dynamiclly generate a class definition?

See
http://docs.python.org/library/functions.html?highlight=type#type
<http://docs.python.org/library/functions.html?highlight=type#type>

From the example:

>>>  class  X(object):
... a  =  1

Is exactly the same as doing...

>>>  X  =  type('X',  (object,),  dict(a=1))

No exec required...

Regards
Phil



On 16/04/2012 17:19, Arruda wrote:

I'm doing something like this to generate some
models dynamically:

SIMILAR_MODELS_TEMPLATE=
"""
@some_decorator
class %(PREFIX)sModel (Some_Abs_model):
\"""%(DESCRIPTION)s
\"""
pass
"""


then I have a factory:

def similar_models_factory(prefix,description):
 format_dict = {
  'PREFIX' : prefix,
  'DESCRIPTION' : description,
 }
 cls_name = "%sModel" % prefix
 cls_source = SIMILAR_MODELS_TEMPLATE % format_dict

 exec(cls_source)
 new_cls = locals().get(cls_name)
 return new_cls


And finally I have in the models.py:

from my_factories import similar_models_factory

SIMILAR_MODELS_LIST =(
{'prefix': 'Foo', 'desc' : 'Foo model and etc..',},
{'prefix': 'Bars', 'desc' : 'Bars model and
etc..',},
.
)

for smodel in SIMILAR_MODELS_LIST:
cls = similar_models_factory(smodels['prefix'],
smodels['desc'])
vars()[cls.__name__] = cls


And this gives my just what I want, but I read somewhere
that if you do:

exec ""

It would be too costly, and I would like to know if this
would have some heavy load in my project(and if please,
how can I calculate this, to compare?)
Thanks!
-- 
You received this message because you are subscribed to

the Google Groups "Django users" group.
To view this discussion on the web visit
https://groups.goo

Re: python list in javascript

[Philip Mountifield]

"title" is never defined in that code snippet so it would be None. Did 
you mean "key"? The syntax looks wrong too for assigning to someobject.


On 20/04/2012 13:53, dummyman dummyman wrote:

Hi,

I have a python dictionary which i want to add to the javascript 
object on load in django template


i followed this method

Re: Django static files STATIC_ROOT vs STATICFILES_FINDERS

[Philip Mountifield]

There is a slight difference:

 * STATIC_ROOT is where you would like the files to be collected to
   when you run "manage.py collectstatic" and should be empty to begin
   with.
 * STATICFILES_DIRS is where the actual files are located and they will
   be automagically servered under the development server.
 * You can also create a folder called "static" in any app and put
   files in there.

Regards
Phil


On 23/04/2012 12:32, gnesher wrote:

Hi,

I'm not sure if this is a bug or am I missing something but I've
created a very simple test environment and placed a single png file
within my static folder.

The file is being served fine when I set :
STATIC_ROOT = ''
STATICFILES_DIRS = (
 '/Users/guynesher/Work/play/quicktest/testproj/static/',
)

however I'm geting a 404 error when I set it like this :
STATIC_ROOT = '/Users/guynesher/Work/play/quicktest/testproj/static/'
STATICFILES_DIRS = (
)

Based on the STATICFILES_DIRS comment (Additional locations of static
files) I expected I will only need to use it if I have multiple static
files directory which doesn't seem to be the case.

What am I missing here?




--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django static files STATIC_ROOT vs STATICFILES_FINDERS

[Philip Mountifield]

It depends how you are running. When using "manage.py runserver" it 
serves the static files for you, without even needing to collect them 
IIRC. But when deploying, you have to run "manage.py collectstatic" and 
Django collects all the files from the other locations for you and puts 
them in STATIC_ROOT, which you would configure your webserver to serve 
at STATIC_URL. The docs are pretty clear on this:


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

Regards
Phil

On 23/04/2012 12:49, gnesher wrote:

But then shouldn't I expect the files to be served from the
STATIC_ROOT as well ?


On Apr 23, 12:38 pm, Philip Mountifield
wrote:

There is a slight difference:

   * STATIC_ROOT is where you would like the files to be collected to
 when you run "manage.py collectstatic" and should be empty to begin
 with.
   * STATICFILES_DIRS is where the actual files are located and they will
 be automagically servered under the development server.
   * You can also create a folder called "static" in any app and put
 files in there.

Regards
Phil

On 23/04/2012 12:32, gnesher wrote:










Hi,
I'm not sure if this is a bug or am I missing something but I've
created a very simple test environment and placed a single png file
within my static folder.
The file is being served fine when I set :
STATIC_ROOT = ''
STATICFILES_DIRS = (
  '/Users/guynesher/Work/play/quicktest/testproj/static/',
)
however I'm geting a 404 error when I set it like this :
STATIC_ROOT = '/Users/guynesher/Work/play/quicktest/testproj/static/'
STATICFILES_DIRS = (
)
Based on the STATICFILES_DIRS comment (Additional locations of static
files) I expected I will only need to use it if I have multiple static
files directory which doesn't seem to be the case.
What am I missing here?

--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.netwww.formac.netwww.telgas.net



--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Error: App with label world could not be found. Are you sure your INSTALLED_APPS setting is correct?

[Philip Mountifield]

I would try importing the module from the python shell, you may have a 
syntax error in that module which is causing manage.py to ignore it. Try 
"python manage.py shell" and then do "import world" or what ever the 
path to your world package is.


Phil

On 07/09/2012 06:50, Coulson Thabo Kgathi wrote:

Yep i do have it.
--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/nbPRkHR6zBkJ.

To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How does threading and processes work in Django

[Philip Mountifield]

I think what you are looking for is Celery (http://celeryproject.org/). 
This handles asynchronous tasks in a clean and tidy manor meaning your 
normal requests are free to return their responses while processing 
continues. You can check the results of tasks later on in another request.


Regards
Philip

On 26/10/2012 03:56, dwang wrote:

Hi,

I'm new to Django and need some help understanding how threading works 
in Django. I have some data that I'd like to recompute periodically in 
the background and have it shared between requests. If I start a 
thread in one of the view functions (e.g. my_thread.start()), would 
Django kill this thread at some point? What if I start the thread in 
the main function before entering the server loop?
Does Django handle each request in a separate process with its own 
interpreter instance?
Where can I find a good explanation of how thread management works in 
Django?


Any pointers would be greatly appreciated!
Danyao


--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/UlalOvj7a9EJ.

To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Philip Mountifield]

Has anyone else experienced this error? Any help would be appreciated.

Thanks

Philip

On 23/09/2011 14:40, Philip wrote:

Just been updating to Django 1.3.1 and come across an odd error. I'm
getting the following error from some code which works with version
1.2.7.

FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

The odd thing being email_config_set is a related name for a
ManyToMany field. I'm not sure why django is trying to resolve it into
a field.

To make it even more odd, this error occurs when DEBUG = TRUE and not
when DEBUG = FALSE when testing with runserver.

I've been trying to solve this for days now with much googling/pdb/
logging, but since the exception originates deep inside django I'm not
familiar enough to find what is going wrong:

Traceback (most recent call last):
   File "./core/driver.py", line 268, in run
 self.init_norm()
   File "./driver/emailevent/background.py", line 130, in init_norm
 self.load_config()
   File "./driver/emailevent/background.py", line 71, in load_config
 events = list(config.events.select_related())
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/manager.py", line 168, in select_related
 return self.get_query_set().select_related(*args, **kwargs)
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/fields/related.py", line 497, in get_query_set
 return
superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/query.py", line 550, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/query.py", line 568, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1194, in add_q
 can_reuse=used_aliases, force_having=force_having)
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1069, in add_filter
 negate=negate, process_extras=process_extras)
   File "/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
django/db/models/sql/query.py", line 1260, in setup_joins
 "Choices are: %s" % (name, ", ".join(names)))
FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

Any ideas/solutions/pointers/tips would be most welcome.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Philip Mountifield]

I am indeed using psycopyg2 and pg8.1, which version did you move to in 
order to solve the problem? I have just been using 8.1 since it was the 
default for CentOS 5, but I also see the 8.4 is available via yum.


Philip

On 26/09/2011 11:20, David Markey wrote:

I had some problems with 1.3 and Postgres 8.1,

Are you using psycopg2 and pg 8.1?

On 26 September 2011 11:16, Russell Keith-Magee 
mailto:russ...@keith-magee.com>> wrote:


Hi Philip,

I can't say I've seen the error you report.

My immediate question when I see reports like this is "what else are
you doing?". Django has an extensive test suite, and things like m2m
fields are tested very heavily. Outside of Django's test suite, there
are thousands of applications out there using Django, and many of them
are using Django 1.3, and this is the first time that this particular
problem has been reported. So, you are clearly doing *something* that
is unusual (whether you know it's unusual or not).

What we need is a reproducible test case -- the smallest possible
sample of code that works under 1.2.7, but breaks under 1.3.1. That
will provide us the basis on which to debug the problem, and form the
core of a regression test to make sure the problem doesn't occur again
in the future.

Yours,
Russ Magee %-)

    On Mon, Sep 26, 2011 at 4:27 PM, Philip Mountifield
mailto:pmountifi...@formac.net>> wrote:
> Has anyone else experienced this error? Any help would be
appreciated.
>
> Thanks
>
> Philip
>
> On 23/09/2011 14:40, Philip wrote:
>>
>> Just been updating to Django 1.3.1 and come across an odd
error. I'm
>> getting the following error from some code which works with version
>> 1.2.7.
>>
>> FieldError: Cannot resolve keyword 'email_config_set' into field.
>> Choices are: id, name, site, type
>>
>> The odd thing being email_config_set is a related name for a
>> ManyToMany field. I'm not sure why django is trying to resolve
it into
>> a field.
>>
>> To make it even more odd, this error occurs when DEBUG = TRUE
and not
>> when DEBUG = FALSE when testing with runserver.
>>
>> I've been trying to solve this for days now with much googling/pdb/
>> logging, but since the exception originates deep inside django
I'm not
>> familiar enough to find what is going wrong:
>>
>> Traceback (most recent call last):
>>   File "./core/driver.py", line 268, in run
>> self.init_norm()
>>   File "./driver/emailevent/background.py", line 130, in init_norm
>> self.load_config()
>>   File "./driver/emailevent/background.py", line 71, in load_config
>> events = list(config.events.select_related())
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/manager.py", line 168, in select_related
>> return self.get_query_set().select_related(*args, **kwargs)
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/fields/related.py", line 497, in get_query_set
>> return
>>
>>

superclass.get_query_set(self).using(db)._next_is_sticky().filter(**(self.core_filters))
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/query.py", line 550, in filter
>> return self._filter_or_exclude(False, *args, **kwargs)
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/query.py", line 568, in _filter_or_exclude
>> clone.query.add_q(Q(*args, **kwargs))
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1194, in add_q
>> can_reuse=used_aliases, force_having=force_having)
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1069, in add_filter
>> negate=negate, process_extras=process_extras)
>>   File
"/usr/local/lib/python2.6/site-packages/Django-1.3.1-py2.6.egg/
>> django/db/models/sql/query.py", line 1260, in setup_joins
>> "Choices are: %s" % (name, ", ".join(names)))
>> FieldError: Cannot resolve keyword 'email_config_set' into field.
>> Choices are: id, name, site, type
>>
>> Any ideas

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Philip Mountifield]

I also have a great deal of dynamically generated models. Interestingly 
in my case I find the issue when using the development server with DEBUG 
= TRUE, I've not yet tried it in deployment.


I'll take a look at your github, thanks for sharing the link.

Out of interest, with respect to David's comment about postgres 
versions, do you use version 8.1 or another?


Phil

On 26/09/2011 11:27, Matthias Kestenholz wrote:

Hi Philip

On Fri, Sep 23, 2011 at 3:40 PM, Philip  wrote:

FieldError: Cannot resolve keyword 'email_config_set' into field.
Choices are: id, name, site, type

Any ideas/solutions/pointers/tips would be most welcome.

Yes, I've seen similar problems in two sites I'm running. I suspect it
has to do with dynamically created models and startup timing effects
in our case. I'm not sure when it started and it's really hard to test
because it only happens in production (mod_wsgi / DEBUG=False) and I
don't have a consistent view of when the problem happens yet.

What we are doing in FeinCMS against it is trying to remove the caches
on Model._meta when new models are being created; this works for us,
but isn't all that nice. I'm running the following code in production
and will be waiting a few hours / days for the problem to manifest
itself again, hoping it wont:
https://github.com/matthiask/feincms/commit/f2de708a09f8b6cf4fdbca6b3583747b6ebbc2e2


Matthias




--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Multiple Image Field in a model

[Philip Mountifield]

I would put the images in a seperate model such as "ReportImage" and 
make a foreign key to "Report", and finally I'd use the "inlines" admin 
feature for ReportImages to display them on the same page as the report.


Phil

On 26/09/2011 15:02, NavaTux wrote:

Hi all,

I have a filed(ImageField) in my model.Also I want to have
multiple ImageFields.How to have more than one ImageFields only in
django model.Is there any need to derive that ImageField as a seperate
new model which holds as a foreign key of another one?

This is my model:

class Report(models.Model):
 name = models.CharField(max_length=1024)
 data = models.TextField()
 image = models.ImageField(upload_to=settings.IMAGE_UPLOAD_PATH,
blank=True, null=True)

I need to display atleast 4 imagefields for this model object?




--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Philip Mountifield]

So I've had a further look into this.

Firstly, I updated to PG 8.4, and found the the issue is still there. 
Secondly I had a look at Matthias' code on github and tries a few hacks. 
I found that clearing the caches on the opposite side of the many to 
many relationship solved the problem.


E.g. for "an_instance.a_many_to_many_field" I cleared the caches in 
"an_instance.a_many_to_many_field.model._meta"


Now I'm going to look into the creation of the dynamic models to see 
what has changed between Django 1.2 and 1.3 in how this happens and 
their sequence.


Philip

On 26/09/2011 11:37, Matthias Kestenholz wrote:

On Mon, Sep 26, 2011 at 12:36 PM, Matthias Kestenholz  wrote:

On Mon, Sep 26, 2011 at 12:34 PM, Philip Mountifield
  wrote:

I also have a great deal of dynamically generated models. Interestingly in
my case I find the issue when using the development server with DEBUG =
TRUE, I've not yet tried it in deployment.

I'll take a look at your github, thanks for sharing the link.

Out of interest, with respect to David's comment about postgres versions, do
you use version 8.1 or another?


(Sorry for pressing send too early.)


We don't use postgresql at all (unfortunately, but that's a different
topic) on the site in question.


Matthias


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Newbee question about PostgreSQL

[Philip Mountifield]

Have you sent a HUP signal to the postmaster or restarted the service 
since making those changes?


Regards, Phil

On 17/10/2011 13:45, Nico wrote:

Thanks for the feedback!

I have edited /etc/postgresql/8.4/main/pg_hba.conf and added the
following line at the bottom:
local   myproject   george  trust
(by the way; I am using a Kubuntu workstation)

It should give me local access using a trusted connection for the
database myproject, for user george.

However, psql still refuses the connection:
psql myproject -U george

This is a PostgreSQL related problem.
Any ideas what I overlook here?

Regards, Nico




--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Newbee question about PostgreSQL

[Philip Mountifield]

The order of configuration in the file is also important; on a 
connection attempt the records are examined sequentially. Perhaps you 
problem lies here if you just added the new details to the bottom of the 
config file.


Regards, Phil

On 17/10/2011 14:01, Nico wrote:

Yes, I have restarted the service.
Of course :)

Nico

On Oct 17, 2:47 pm, Philip Mountifield
wrote:

Have you sent a HUP signal to the postmaster or restarted the service
since making those changes?

Regards, Phil



--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Why does collectstatic finds static files in admin 'media' directory?

[Philip Mountifield]

I found this a little while ago and reported the mistake in the docs. 
There is an exception made in the code for the admin media to preserve 
backwards compatibility, and allow the files to remain in "media" rather 
than "static".


Regards
Phil

On 15/11/2011 16:34, Ivo Brodien wrote:

Hi,

on 1.3.1. I ran:

./manage.py collectstatic --dry-run

and it found files in: django/contrib/admin/media/

which is fine, but I am wondering, why these files are found since the docs 
says, that the default folder apps have to store there static assets is a 
folder called “static”.

I haven’t added anything to STATICFILES_DIRS or STATICFILES_FINDERS

Thanks for clarification.

PS: I am upgrading from 1.2.5 to 1.3.1 so my setting.py file is actually an 
"old one”  with the added settings for the static stuff.



--

Philip Mountifield
Formac Electronics Ltd
tel  +44 (0) 1225 837333
fax  +44 (0) 1225 430995

pmountifi...@formac.net
www.formac.net
www.telgas.net

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: pre_save on password

[Philip Mountifield]

If the username/whatever is available within the hasher you could create 
a subclass of the hasher you're using in Django and intercept the 
plain-text password there, call your API and then call the superclass?


Phil

On 01/07/2014 13:27, guillaume wrote:

Hi Tom,

Yes indeed, I know that page, but there is no way I can make it the 
same than the other one which relies on SHA256, some system key I 
don't know and a random salt. So there is no way for me to find the 
correct encryption for the remote database, that's why I want to use 
it's API registration system and feed it with the clear password.


Best regards

Guillaume

Le mardi 1 juillet 2014 14:17:28 UTC+2, Tom Evans a écrit :

On Tue, Jul 1, 2014 at 1:12 PM, guillaume > wrote:
>
> Hi,
> thanks for your reply. Actually I don't want to store the uncrypted
> password, just submit it to another app registration system,
which will hash
> it then. The two hashing systems are too different and
complicated for me to
> use the django encrypted password in the other application
database.
>

How Django hashes passwords is fully configurable, see:

https://docs.djangoproject.com/en/1.6/topics/auth/passwords/


The setting PASSWORD_HASHERS contains a list of classes that hash
passwords. Simply replace this with your custom hash algorithm, or
calls to your external API that implements your hash algorithm.

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/a7b49845-b8df-4897-b653-17020f339794%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/53B2B19F.1030704%40formac.net.
For more options, visit https://groups.google.com/d/optout.