Mod_python error: "PythonHandler django.core.handlers.modpython"

[moberley]

I tried to set-up a django project using mod_python on Apache/1.3.33
and I can only get mod_python error messages. The admin part displays
the following traceback (it works fine with django-admin.py runserver):

-

Mod_python error: "PythonHandler django.core.handlers.modpython"

Traceback (most recent call last):

  File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py",
line 193, in Dispatch
result = object(req)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 164, in handler
return ModPythonHandler()(req)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 139, in __call__
response = self.get_response(req.uri, request)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/base.py",
line 50, in get_response
response = middleware_method(request)

  File
"/usr/local/lib/python2.4/site-packages/django/middleware/sessions.py",
line 56, in process_request
request.session =
SessionWrapper(request.COOKIES.get(SESSION_COOKIE_NAME, None))

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 53, in _get_cookies
self._cookies =
httpwrappers.parse_cookie(self._req.headers_in.get('cookie', ''))

AttributeError: get

-

The regular side displays a different traceback (this also works with
django-admin.py).

Mod_python error: "PythonHandler django.core.handlers.modpython"

Traceback (most recent call last):

  File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py",
line 193, in Dispatch
result = object(req)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 164, in handler
return ModPythonHandler()(req)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 139, in __call__
response = self.get_response(req.uri, request)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/base.py",
line 50, in get_response
response = middleware_method(request)

  File
"/usr/local/lib/python2.4/site-packages/django/middleware/common.py",
line 33, in process_request
if request.META.has_key('HTTP_USER_AGENT'):

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 67, in _get_meta
self._meta = {

  File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py",
line 85, in __getattr__
raise AttributeError, attr

AttributeError: ap_auth_type

Re: Mod_python error: "PythonHandler django.core.handlers.modpython"

[moberley]

Sorry, I seem to have forgotten to close my message properly.

I've tried searching for information about this, but I was unable to
find anything obvious and it's a little bit beyond my knowledge of
Apache. Does anyone have any ideas what I might try to make this work?

Thanks,
Bradley Peters

Re: Table-less model as base class?

[Eric Walstad]

Adrian Holovaty wrote:
> On 9/18/05, Eric Walstad <[EMAIL PROTECTED]> wrote:
[...]
> > Is it possible to do what I want, move common fields to a super class,
> > without generating a table for that super class?
>
> It's not currently possible, but that exact functionality is on the
> to-do list: http://code.djangoproject.com/ticket/419 .
>
> Adrian

Hi Adrian,
I'm short on time, but I think I may have hacked up something that
works (for me) and passes the unit tests.

Eric.

[EMAIL PROTECTED] django_src]$ diff -u
django/core/meta/__init__.py.orig django/core/meta/__init__.py
--- django/core/meta/__init__.py.orig   2005-09-18 14:51:18.0
-0700
+++ django/core/meta/__init__.py2005-09-18 15:59:20.0
-0700
@@ -412,6 +412,11 @@
 # attribute order.
 fields.sort(lambda x, y: x.creation_counter -
y.creation_counter)

+# Should this class generate database tables (Default is Yes)?
+# This has the ultimate effect of keeping this class out of
the _MODELS
+# list.
+create_table = not (meta_attrs.pop('no_table', False))
+
 # If this model is a subclass of another model, create an
Options
 # object by first copying the base class's _meta and then
updating it
 # with the overrides from this class.
@@ -673,7 +678,9 @@
 # contain this list:
 # [, ]
 # Don't do this if replaces_module is set.
-app_package.__dict__.setdefault('_MODELS',
[]).append(new_class)
+# Exclude models where the user has set 'no_table = True'
+if create_table:
+app_package.__dict__.setdefault('_MODELS',
[]).append(new_class)

 # Cache the app label.
 opts.app_label = app_label
@@ -725,6 +732,7 @@
 def __repr__(self):
 return '<%s object>' % self.__class__.__name__

+
 
 # HELPER FUNCTIONS (CURRIED MODEL METHODS) #
 
[EMAIL PROTECTED] django_src]$ python tests/runtests.py
Running tests with database 'postgresql'
All tests passed.


experiment.py file:
from django.core import meta

class MyBaseClass(meta.Model):
"""This class will not result in any tables being generated by
django"""
created_on = meta.DateTimeField(auto_now_add=True)
modified_on = meta.DateTimeField(auto_now=True)
class META:
no_table = True

class MyDerived(MyBaseClass):
"""This class will have tables generated and will include the:
 - created_on and
 - modified_on fields
which are inherited from the 'MyBaseClass' class.
"""
name = meta.CharField(maxlength=25)
class META:
   module_name = 'my_derived_class'

class MyOtherDerived(MyDerived):
"""This class will not result in any tables being generated by
django and
it will include all the fields inherited from both 'MyBaseClass'
and
'MyDerived' as well as those fields defined here.
"""
color = meta.CharField(maxlength=25)
class META:
module_name = 'my_other_derived'
# Explicitly set the no_table flag so that this class doesn't
result in
# a table being created.
no_table = True

class MyLastDerived(MyOtherDerived):
"""This class will have tables generated and will include the:
 - created_on and
 - modified_on fields
which are inherited from the 'MyBaseClass' class,
 - name
which is inherited from the 'MyDerived' class and
 - color
which is inherited from the 'MyOtherDerived' class as well as those
fields
defined here.
"""
size = meta.IntegerField(choices=((0, 'small'),
  (1, 'medium'),
  (2, 'large'),
  ))
class META:
module_name = 'my_last_derived'


[EMAIL PROTECTED] django_src]$ django-admin.py sql experiment
BEGIN;
CREATE TABLE experiment_my_derived_class (
id serial NOT NULL PRIMARY KEY,
modified_on timestamp with time zone NOT NULL,
created_on timestamp with time zone NOT NULL,
name varchar(25) NOT NULL
);
CREATE TABLE experiment_my_last_derived (
id serial NOT NULL PRIMARY KEY,
color varchar(25) NOT NULL,
modified_on timestamp with time zone NOT NULL,
created_on timestamp with time zone NOT NULL,
name varchar(25) NOT NULL,
size integer NOT NULL
);

Re: TurboGears

[Samat Jain]

On Sunday 18 September 2005 03:55 am, Andreas wrote:
> I just discovered TurboGears, another MVC web development framework
> based on Python (turbogears.org). Judging from the 20-Minute-Demo-Video
> it seems to be quite similar to Django, although lacking the slick
> admin interface. What do you think about it? How does it compare to
> Django?

They appear to be much more focused on using existing projects rather than 
writing their own.

For example, for an ORM they use SQLobject, compared to Django which has it's 
own. I personally like SQLobject, especially the way it handles inheritance, 
which is different (and "better" for some of the ideas I've in mind) than in 
Django.

Samat

-- 
Samat Jain 

Advertising is a valuable economic factor because it is the cheapest way of 
selling goods, particularly if the goods are worthless.
-- Sinclair Lewis (416)

Re: Table-less model as base class?

[Adrian Holovaty]

On 9/18/05, Eric Walstad <[EMAIL PROTECTED]> wrote:
> I'd like to make a base class for my model classes that defines some
> fields but doesn't result in a table in the database.  If my base class
> is derived from meta.Model, then django makes a table for it in the
> database.
> 
> Is it possible to do what I want, move common fields to a super class,
> without generating a table for that super class?

It's not currently possible, but that exact functionality is on the
to-do list: http://code.djangoproject.com/ticket/419 .

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

Re: befuddled with formfields.py

[scottpierce]

I don't know that I would call it hacking around.  Yes.  There seems to
be a lot of stuff within the admin that is not exposed outside of the
admin.  Manipulators will act accordingly if given formfieldcollections
for "inline" tables; however, they aren't exposed outside the admin as
they should or could be.  I have been working on some stuff to expose
this functionality and have it working but it isn't ready for prime
time.

Re: befuddled with formfields.py

[Robert Wittams]

scottpierce wrote:
> See http://code.djangoproject.com/ticket/338.  The patch works.
> 
> Scott Pierce
> 
> 

So basically, mainipulators are completely useless when it comes to
ForeignKeys and ManyToManys and need to be hacked around in the view
function?

This is a horrible fix. I'm going to fix it properly...  I didn't
realise the admin views hacked it about that much

New Free Downloads

[Jimm]

Hello everyone!
After few months of hard work, my site with free downloads is finally
up and running. I have tried to create a site that goes right to the
point and cuts through all of the software downloads. Having read this
group for quite a while, it looks like there are a lot of knowledgeable
people here, so I'd love to get some feedback about my site if anyone
can spare the time. The site is located at
http://www.freedownloadsarchive.com/ and called "Free Downloads
Archive".


I think that website are quite good, but I'm not so satisfied with
others, so I'd be grateful if you could tell me what you think?


Thanks in advance,
Jimm, Webmaster of Free Download Archive
Download Free Software NOW: http://www.freedownloadsarchive.com/

TurboGears

[Andreas]

I just discovered TurboGears, another MVC web development framework
based on Python (turbogears.org). Judging from the 20-Minute-Demo-Video
it seems to be quite similar to Django, although lacking the slick
admin interface. What do you think about it? How does it compare to
Django?

Re: befuddled with formfields.py

[scottpierce]

See http://code.djangoproject.com/ticket/338.  The patch works.

Scott Pierce

Re: Strange problem with dates after importing django models

[Jacob Kaplan-Moss]

On Sep 17, 2005, at 6:27 PM, [EMAIL PROTECTED] wrote:


datetime.now() seems to be offset by 6 hours backwards after I import
one of my django models:



import datetime
datetime.datetime.now()



datetime.datetime(2005, 9, 18, 0, 21, 16, 456425)



import django.models.sitecontent
datetime.datetime.now()



datetime.datetime(2005, 9, 17, 18, 22, 1, 857014)

The model in question doesn't even have any date/datetime fields.

Any idea what could be going on here?  It affects my website just the
same as interactive.



Django does some time zone stuff to make sure that settings times in  
the admin makes sense; this most likely means you'll need to change  
the TIME_ZONE setting in your settings file (it defaults to "America/ 
Chicago", which is the time zone we live in).


Jacob