Weird behaviour

[Elver Loho]

request.session seems to be storing things beyond me closing the
Django development server. This is sort of weird. Is it a feature or a
bug? Because, I'd prefer a clean slate every time I run the devserver.


Example code:
def foo(request):

foo = request.session.get("foo", None)

print "foo is", str(foo)

if foo == None:
request.session["foo"] = "Haha! Not None!"

Behaviour:
# Server started
# First run: "foo is None"
# Second run: "foo is Haha! Not None!"
# Server closed

# Server started
# First run: "foo is Haha! Not None!"


This behaviour is just way too weird. I'm currently developing with
Django for work and with CherryPy for a side project and CherryPy
doesn't store sessions beyond the lifetime of the server. I sort of
didn't expect this behaviour from Django either.

So, this a bug or a feature? And how can I turn it off?


Elver

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Adrian Holovaty]

On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> This behaviour is just way too weird. I'm currently developing with
> Django for work and with CherryPy for a side project and CherryPy
> doesn't store sessions beyond the lifetime of the server. I sort of
> didn't expect this behaviour from Django either.
>
> So, this a bug or a feature? And how can I turn it off?

Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.

http://www.djangoproject.com/documentation/sessions/#browser-length-sessions-vs-persistent-sessions

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[arthur debert]

Hi Elver.

This is a feature.
This behaviour depends on wheter you want yor sessions to expire and
when. More details in the docs:
http://www.djangoproject.com/documentation/sessions/#browser-length-sessions-vs-persistent-sessions

arthur


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Elver Loho]

On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > This behaviour is just way too weird. I'm currently developing with
> > Django for work and with CherryPy for a side project and CherryPy
> > doesn't store sessions beyond the lifetime of the server. I sort of
> > didn't expect this behaviour from Django either.
> >
> > So, this a bug or a feature? And how can I turn it off?
>
> Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.

That simply sets the cookie to expire when the browser is closed.
That's not a solution since I've got Firefox open in 3-4 workspaces
here, with several tabs in each instance. I'm sure as hell *not* going
to close every last instance every time I change something in the code
and want to start all over again...

I think it's a bug that Django's session variables survive when the
Django development server is closed. Yes, when I close the browser,
it's nice that I can start it again and be greeted with my session.
However, when I close the server, I expect the session to be lost.

How can I tell Django to store the sessions in memory and drop them
when the server is closed?


Elver

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Adrian Holovaty]

On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> I think it's a bug that Django's session variables survive when the
> Django development server is closed. Yes, when I close the browser,
> it's nice that I can start it again and be greeted with my session.
> However, when I close the server, I expect the session to be lost.
>
> How can I tell Django to store the sessions in memory and drop them
> when the server is closed?

Django sessions are stored in the database, not in memory. That
decision has its roots in the fact that Django's recommended
development platform is mod_python, and mod_python processes don't
share memory. Plus, the permanence of having session data in the
database is just more robust; personally, I'm scared by storing
important data only in memory.

If you want to do this nevertheless, you can easily write a middleware
class that works like Django's SessionMiddleware but saves its session
data in memory. You could also check out the patch here:

http://code.djangoproject.com/ticket/2066

Hope this helps,
Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Malcolm Tredinnick]

On Thu, 2006-06-08 at 02:21 +0300, Elver Loho wrote:
> On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > This behaviour is just way too weird. I'm currently developing with
> > > Django for work and with CherryPy for a side project and CherryPy
> > > doesn't store sessions beyond the lifetime of the server. I sort of
> > > didn't expect this behaviour from Django either.
> > >
> > > So, this a bug or a feature? And how can I turn it off?
> >
> > Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.
> 
> That simply sets the cookie to expire when the browser is closed.
> That's not a solution since I've got Firefox open in 3-4 workspaces
> here, with several tabs in each instance. I'm sure as hell *not* going
> to close every last instance every time I change something in the code
> and want to start all over again...
> 
> I think it's a bug that Django's session variables survive when the
> Django development server is closed. Yes, when I close the browser,
> it's nice that I can start it again and be greeted with my session.
> However, when I close the server, I expect the session to be lost.

Move beyond the development server for a moment and think about sessions
in the more general concept. Generally, it is not desirable for a
client's session to be lost just because the backend webserver is
restarted. Session-based cookies behave according to browser lifetime,
not server lifetime.

However, if you want the server to no longer recognise the client's
cookie, then the solution is to clear out the django_session table from
the database each time. I'm not sure this is really something we want to
do each time we stop and start -- because most of the time you don't
want to have to re-login and everything. But if you do need it all the
time, then it is easy enough to create a shell script that runs "delete
from django_session" prior to doing "exec manage.py runserver". Or catch
the termination the dev server and do the deletion at that point,
although that is a little more fiddly.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Elver Loho]

On 6/8/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2006-06-08 at 02:21 +0300, Elver Loho wrote:
> > On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > >
> > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > > This behaviour is just way too weird. I'm currently developing with
> > > > Django for work and with CherryPy for a side project and CherryPy
> > > > doesn't store sessions beyond the lifetime of the server. I sort of
> > > > didn't expect this behaviour from Django either.
> > > >
> > > > So, this a bug or a feature? And how can I turn it off?
> > >
> > > Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.
> >
> > That simply sets the cookie to expire when the browser is closed.
> > That's not a solution since I've got Firefox open in 3-4 workspaces
> > here, with several tabs in each instance. I'm sure as hell *not* going
> > to close every last instance every time I change something in the code
> > and want to start all over again...
> >
> > I think it's a bug that Django's session variables survive when the
> > Django development server is closed. Yes, when I close the browser,
> > it's nice that I can start it again and be greeted with my session.
> > However, when I close the server, I expect the session to be lost.

> Move beyond the development server for a moment and think about sessions
> in the more general concept.

The point is, I'm doing this on the development server. It's the
*development* server. It's not Apache with mod_python. And in Django's
docs it is said that people should not use the development server for
anything but, well, development.

Everything you've just said makes a lot of sense on a production
rollout. Yes, do keep sessions after shutdown. It's a great feature!
But this "feature" on the development server simply makes development
more difficult.

So, um, could someone add a feature to the SVN version to let me turn
this off? Please? Pretty please? With sugar on top? :)


Elver

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Adrian Holovaty]

On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> Everything you've just said makes a lot of sense on a production
> rollout. Yes, do keep sessions after shutdown. It's a great feature!
> But this "feature" on the development server simply makes development
> more difficult.
>
> So, um, could someone add a feature to the SVN version to let me turn
> this off? Please? Pretty please? With sugar on top? :)

This is too much feature creep for my liking, and I don't see how it
makes development more difficult for the common case. Just put these
two commands in a shell script and off you go:

python -c 'from django.contrib.sessions.models import Session; \
Session.objects.all().delete()'
python manage.py runserver

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Elver Loho]

On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > Everything you've just said makes a lot of sense on a production
> > rollout. Yes, do keep sessions after shutdown. It's a great feature!
> > But this "feature" on the development server simply makes development
> > more difficult.
> >
> > So, um, could someone add a feature to the SVN version to let me turn
> > this off? Please? Pretty please? With sugar on top? :)
>
> This is too much feature creep for my liking, and I don't see how it
> makes development more difficult for the common case. Just put these
> two commands in a shell script and off you go:
>
> python -c 'from django.contrib.sessions.models import Session; \
> Session.objects.all().delete()'
> python manage.py runserver

Hmmm... I'll do some thinking on this. Anyhow, someone said earlier
that keeping session variables in the database is a good idea in case
the server is shut down or crashes or whatnot.

I think it's a bad idea. For the same reason.

Suppose you have a controller function that sets a number of session
variables throughout its execution. Suppose the server loses power or
whatnot when the function is half way done. Now, half the session
variables that would be set are set and in the database. The other
half are not.

When the server comes back on, this inconsistency in the database
could cause all sorts of weird problems and bugs.

Suppose the session variable "logged_in" is set to "True", but the
execution stops right before "username" is set to the user's username.
When the server comes back online, you have a potential security
issue.

It makes no sense to persist sessions beyond server lifetime. If you
want to commit some change, commit it to the database. Session
variables should be treated as regular variables.


Elver

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Honza Král]

and do you really think that sessions are saved after each variable
set into the database?
I hope not...

they are probably only saved after the return of the view, or
somewhere around that point...

On 6/8/06, Elver Loho <[EMAIL PROTECTED]> wrote:
>
> On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > Everything you've just said makes a lot of sense on a production
> > > rollout. Yes, do keep sessions after shutdown. It's a great feature!
> > > But this "feature" on the development server simply makes development
> > > more difficult.
> > >
> > > So, um, could someone add a feature to the SVN version to let me turn
> > > this off? Please? Pretty please? With sugar on top? :)
> >
> > This is too much feature creep for my liking, and I don't see how it
> > makes development more difficult for the common case. Just put these
> > two commands in a shell script and off you go:
> >
> > python -c 'from django.contrib.sessions.models import Session; \
> > Session.objects.all().delete()'
> > python manage.py runserver
>
> Hmmm... I'll do some thinking on this. Anyhow, someone said earlier
> that keeping session variables in the database is a good idea in case
> the server is shut down or crashes or whatnot.
>
> I think it's a bad idea. For the same reason.
>
> Suppose you have a controller function that sets a number of session
> variables throughout its execution. Suppose the server loses power or
> whatnot when the function is half way done. Now, half the session
> variables that would be set are set and in the database. The other
> half are not.
>
> When the server comes back on, this inconsistency in the database
> could cause all sorts of weird problems and bugs.
>
> Suppose the session variable "logged_in" is set to "True", but the
> execution stops right before "username" is set to the user's username.
> When the server comes back online, you have a potential security
> issue.
>
> It makes no sense to persist sessions beyond server lifetime. If you
> want to commit some change, commit it to the database. Session
> variables should be treated as regular variables.
>
>
> Elver
>
> >
>


-- 
Honza Král
E-Mail: [EMAIL PROTECTED]
ICQ#:   107471613
Phone:  +420 606 678585

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Elver Loho]

On 6/8/06, Honza Král <[EMAIL PROTECTED]> wrote:
> and do you really think that sessions are saved after each variable
> set into the database?
> I hope not...
>
> they are probably only saved after the return of the view, or
> somewhere around that point...

Alright then, my mistake. However, it still doesn't make sense to
store sessions on the development server. IMO.

>
> On 6/8/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> >
> > On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > >
> > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > > Everything you've just said makes a lot of sense on a production
> > > > rollout. Yes, do keep sessions after shutdown. It's a great feature!
> > > > But this "feature" on the development server simply makes development
> > > > more difficult.
> > > >
> > > > So, um, could someone add a feature to the SVN version to let me turn
> > > > this off? Please? Pretty please? With sugar on top? :)
> > >
> > > This is too much feature creep for my liking, and I don't see how it
> > > makes development more difficult for the common case. Just put these
> > > two commands in a shell script and off you go:
> > >
> > > python -c 'from django.contrib.sessions.models import Session; \
> > > Session.objects.all().delete()'
> > > python manage.py runserver
> >
> > Hmmm... I'll do some thinking on this. Anyhow, someone said earlier
> > that keeping session variables in the database is a good idea in case
> > the server is shut down or crashes or whatnot.
> >
> > I think it's a bad idea. For the same reason.
> >
> > Suppose you have a controller function that sets a number of session
> > variables throughout its execution. Suppose the server loses power or
> > whatnot when the function is half way done. Now, half the session
> > variables that would be set are set and in the database. The other
> > half are not.
> >
> > When the server comes back on, this inconsistency in the database
> > could cause all sorts of weird problems and bugs.
> >
> > Suppose the session variable "logged_in" is set to "True", but the
> > execution stops right before "username" is set to the user's username.
> > When the server comes back online, you have a potential security
> > issue.
> >
> > It makes no sense to persist sessions beyond server lifetime. If you
> > want to commit some change, commit it to the database. Session
> > variables should be treated as regular variables.
> >
> >
> > Elver
> >
> > >
> >
>
>
> --
> Honza Král
> E-Mail: [EMAIL PROTECTED]
> ICQ#:   107471613
> Phone:  +420 606 678585
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: Weird behaviour

[limodou]

On 6/8/06, Elver Loho <[EMAIL PROTECTED]> wrote:
>
> On 6/8/06, Honza Král <[EMAIL PROTECTED]> wrote:
> > and do you really think that sessions are saved after each variable
> > set into the database?
> > I hope not...
> >
> > they are probably only saved after the return of the view, or
> > somewhere around that point...
>
> Alright then, my mistake. However, it still doesn't make sense to
> store sessions on the development server. IMO.
>
I think clearing all sessions after closing development server maybe
just suit for your situation. And in my case, I'd never thought about
this problem after reading your email :). And I think it's not a
normal behavior to web server. So you could do just like Adiran
advised, either applying the patch, or clearing the session table
yourself. Even using development server, I think it works more like
practical environment more better.

-- 
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Model save() weird behaviour

[Phil]

Hi All,

noticed an interesting behaviour in model save:

class Page(models.Model):
title = models.CharField(_(u"Title"), max_length=50)
fulltitle = models.CharField(_(u"Full Title"), max_length=50)
...

def save():
   # title is received from a form, say i've entered 'QWERTY'
title1 =  str(self.title)
self.fulltitle = title1
#fulltitle = title = 'QWERTY'
self.title = 'sampletext'
super(Article, self).save()

after all i got:
fulltitle = title = 'sampletext'
i was expecting to have:
fulltitle =  'QWERTY'
title = 'sampletext'

so - does it mean that i pass reference to an existing object, not a
value? Do i miss some fundamental thing about Django? :)

Cheers
Phil

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

Custom tag weird behaviour

[__alex__]

Hi all,

I've been trying to figure this out for hours and hours, but I simply
can't understand how to make it work.

Now, we have a very simple custom template tag. Let's say that we want
the template tag to take as a parameter a filtered variable. A very
simple implementation of my template tag is :

register = template.Library()

class Test(template.Node):
def __init__(self,val):
self.val = val
def render(self,context):
print("VALUE=%s" % self.val)
if self.val.__class__.__name__ == "FilterExpression":
self.val = self.val.resolve(context)
return self.val

@register.tag('test')
def test(parser,token):

print("Test is executed")

val = token.split_contents()1
val = parser.compile_filter(val)

return Test(val)

This just gets the value and resolves the filter. A simple template to
test this is :

{% for p in test_list %}
{% test p|first %} - {%test p|last%} --- {{p}}
{% endfor %}

The test_list is :
(("First1","Last1"),("First2","Last2"),("First3","Last3"))

So from the code I've written so far I would expect this silly
template tag to iterate through and print out the first and last
element of the tuples.

Though, this is the output of the template :

First1 - Last1 --- ('First1', 'Last1')
First1 - Last1 --- ('First2', 'Last2')
First1 - Last1 --- ('First3', 'Last3')

And this is what I get in my console:

Test is executed
Test is executed
VALUE=p|first
VALUE=p|last
VALUE=First1
VALUE=Last1
VALUE=First1
VALUE=Last1

OK, so what I understand so far is that the template player calls the
test template tag the first two times. Then, somehow it creates new
Test objects and feeds them with the result of the first execution.

I am certainly not a django expert, so could someone be kind enough to
explain me what on earth is this thing doing and how to get around it
please ? :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Model save() weird behaviour

[Karen Tracey]

On Thu, Jul 16, 2009 at 7:09 AM, Phil  wrote:

>
> Hi All,
>
> noticed an interesting behaviour in model save:
>
> class Page(models.Model):
>title = models.CharField(_(u"Title"), max_length=50)
>fulltitle = models.CharField(_(u"Full Title"), max_length=50)
> ...
>
>def save():
>   # title is received from a form, say i've entered 'QWERTY'
>title1 =  str(self.title)
>self.fulltitle = title1
>#fulltitle = title = 'QWERTY'
>self.title = 'sampletext'
>super(Article, self).save()
>

That can't really be the save() for Page because it's calling super(Article,
self)...?

Karen

--~--~-~--~~~---~--~~
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: Model save() weird behaviour

[Phil]

oh, sorry for that - exampling mistake, should be:

class Page(models.Model):
title = models.CharField(_(u"Title"), max_length=50)
fulltitle = models.CharField(_(u"Full Title"), max_length=50)
...

def save():
   # title is received from a form, say i've entered 'QWERTY'
title1 =  str(self.title)
self.fulltitle = title1
#fulltitle = title = 'QWERTY'
self.title = 'sampletext'
super(Page, self).save()


Thanks for that correction,
Cheers,
Phil

On Jul 16, 9:50 pm, Karen Tracey  wrote:
> On Thu, Jul 16, 2009 at 7:09 AM, Phil  wrote:
>
> > Hi All,
>
> > noticed an interesting behaviour in model save:
>
> > class Page(models.Model):
> >    title = models.CharField(_(u"Title"), max_length=50)
> >    fulltitle = models.CharField(_(u"Full Title"), max_length=50)
> > ...
>
> >    def save():
> >       # title is received from a form, say i've entered 'QWERTY'
> >        title1 =  str(self.title)
> >        self.fulltitle = title1
> >        #fulltitle = title = 'QWERTY'
> >        self.title = 'sampletext'
> >        super(Article, self).save()
>
> That can't really be the save() for Page because it's calling super(Article,
> self)...?
>
> Karen
--~--~-~--~~~---~--~~
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: Model save() weird behaviour

[Phil]

anyone?
any ideas? :)

On Jul 17, 11:00 am, Phil  wrote:
> oh, sorry for that - exampling mistake, should be:
>
> class Page(models.Model):
>     title = models.CharField(_(u"Title"), max_length=50)
>     fulltitle = models.CharField(_(u"Full Title"), max_length=50)
> ...
>
>     defsave():
>        # title is received from a form, say i've entered 'QWERTY'
>         title1 =  str(self.title)
>         self.fulltitle = title1
>         #fulltitle = title = 'QWERTY'
>         self.title = 'sampletext'
>         super(Page, self).save()
>
> Thanks for that correction,
> Cheers,
> Phil
>
> On Jul 16, 9:50 pm, Karen Tracey  wrote:
>
>
>
> > On Thu, Jul 16, 2009 at 7:09 AM, Phil  wrote:
>
> > > Hi All,
>
> > > noticed an interesting behaviour in modelsave:
>
> > > class Page(models.Model):
> > >    title = models.CharField(_(u"Title"), max_length=50)
> > >    fulltitle = models.CharField(_(u"Full Title"), max_length=50)
> > > ...
>
> > >    defsave():
> > >       # title is received from a form, say i've entered 'QWERTY'
> > >        title1 =  str(self.title)
> > >        self.fulltitle = title1
> > >        #fulltitle = title = 'QWERTY'
> > >        self.title = 'sampletext'
> > >        super(Article, self).save()
>
> > That can't really be thesave() for Page because it's calling super(Article,
> > self)...?
>
> > Karen
--~--~-~--~~~---~--~~
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: Model save() weird behaviour

[Brian May]

On Thu, Jul 16, 2009 at 04:09:36AM -0700, Phil wrote:
> def save():
># title is received from a form, say i've entered 'QWERTY'
> title1 =  str(self.title)
> self.fulltitle = title1
> #fulltitle = title = 'QWERTY'
> self.title = 'sampletext'
> super(Article, self).save()
> 
> after all i got:
> fulltitle = title = 'sampletext'
> i was expecting to have:
> fulltitle =  'QWERTY'
> title = 'sampletext'

Why should it do that?

The only line containing QWERTY is commented out, and even if it wasn't
commented out it does nothing. Maybe you meant to say:

self.fulltitle = self.title = 'QWERTY'

As such, what you have is:

self.fulltitle = self.title
self.title = 'sampletext'
self.save()

So the new value of self.fulltitle depends on what self.title previously was.
-- 
Brian May 

--~--~-~--~~~---~--~~
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: Model save() weird behaviour

[Phil]

Thanks Brian,

'QWERTY' goes from the form entry here...but that's not important as
issue is located somewhere else, precisely save is called twice...
apologise for that

Cheers,
Philip

On Jul 21, 2:52 pm, Brian May  wrote:
> On Thu, Jul 16, 2009 at 04:09:36AM -0700, Phil wrote:
> >     defsave():
> >        # title is received from a form, say i've entered 'QWERTY'
> >         title1 =  str(self.title)
> >         self.fulltitle = title1
> >         #fulltitle = title = 'QWERTY'
> >         self.title = 'sampletext'
> >         super(Article, self).save()
>
> > after all i got:
> >         fulltitle = title = 'sampletext'
> > i was expecting to have:
> >         fulltitle =  'QWERTY'
> >         title = 'sampletext'
>
> Why should it do that?
>
> The only line containing QWERTY is commented out, and even if it wasn't
> commented out it does nothing. Maybe you meant to say:
>
> self.fulltitle = self.title = 'QWERTY'
>
> As such, what you have is:
>
> self.fulltitle = self.title
> self.title = 'sampletext'
> self.save()
>
> So the new value of self.fulltitle depends on what self.title previously was.
> --
> Brian May 
--~--~-~--~~~---~--~~
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: Custom tag weird behaviour

[Bill Freeman]

I don't know if you have other problems, but the following is invalid python:

   val = token.split_contents()1

You may have meant:

   val = token.split_contents()[1]

Which gets you the second element of the list returned by split_contents().
If you wanted the first element, change the 1 to a 0.

Bill


On Fri, Jun 4, 2010 at 12:42 PM, __alex__  wrote:
> Hi all,
>
> I've been trying to figure this out for hours and hours, but I simply
> can't understand how to make it work.
>
> Now, we have a very simple custom template tag. Let's say that we want
> the template tag to take as a parameter a filtered variable. A very
> simple implementation of my template tag is :
>
> register = template.Library()
>
> class Test(template.Node):
>        def __init__(self,val):
>                self.val = val
>        def render(self,context):
>                print("VALUE=%s" % self.val)
>                if self.val.__class__.__name__ == "FilterExpression":
>                        self.val = self.val.resolve(context)
>                return self.val
>
> @register.tag('test')
> def test(parser,token):
>
>        print("Test is executed")
>
>        val = token.split_contents()1
>        val = parser.compile_filter(val)
>
>        return Test(val)
>
> This just gets the value and resolves the filter. A simple template to
> test this is :
>
> {% for p in test_list %}
>        {% test p|first %} - {%test p|last%} --- {{p}}
> {% endfor %}
>
> The test_list is :
> (("First1","Last1"),("First2","Last2"),("First3","Last3"))
>
> So from the code I've written so far I would expect this silly
> template tag to iterate through and print out the first and last
> element of the tuples.
>
> Though, this is the output of the template :
>
> First1 - Last1 --- ('First1', 'Last1')
> First1 - Last1 --- ('First2', 'Last2')
> First1 - Last1 --- ('First3', 'Last3')
>
> And this is what I get in my console:
>
> Test is executed
> Test is executed
> VALUE=p|first
> VALUE=p|last
> VALUE=First1
> VALUE=Last1
> VALUE=First1
> VALUE=Last1
>
> OK, so what I understand so far is that the template player calls the
> test template tag the first two times. Then, somehow it creates new
> Test objects and feeds them with the result of the first execution.
>
> I am certainly not a django expert, so could someone be kind enough to
> explain me what on earth is this thing doing and how to get around it
> please ? :)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Custom tag weird behaviour

[__alex__]

Yeah, this was from the copy paste. It is split_contents()[1],
otherwise the code wouldn't run at all ;)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

weird behaviour of forms in render_to_response

[ihome]

Hi,

I am using the latest django development version and have some problem
with the render_to_response to render a template. Here is a short
snippet:

return render_to_response('index.html', {
'form': form,
'ops' : ops,
  })

form comes from a newly defined data form inherited from forms.Form.
For one line in my template index.html:



The rendered html page looks like:

" />

Not sure why the render_to_response want to generate a whole  for my {{  form.v }}

Do I miss anything here? I do not want this pre-defined behaviour. Is
there a way to turn it off. For ops dict type, everything works as
expected.

Thanks.


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

LFS - weird behaviour on image creation

[Simone Orsi]

Hi *,

anybody has faced this?

http://groups.google.de/group/lightning-fast-shop/browse_thread/thread/73cc6a8ec3fa330

TIA,
SimO

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

A weird behaviour of imagestore app

[chuwy]

Hi, all.
I'm trying to install imagestore  app 
in my project. Default models are created succefully, and all other parts 
working properly.
But, it have a feature to extend base (abstract) models and create your own 
by some complicated mechanism. This is mine model:
from django.db import models 
from imagestore.models.bases.album import BaseAlbum 
class Newalbum(BaseAlbum): 
title = models.CharField("title", max_length=128) 
class Meta(BaseAlbum.Meta): 
app_label = "imagestore" 
abstract = False
Also I have a string IMAGESTORE_ALBUM_MODEL = 'art.models.Newalbum'
When I run syncdb it tells me Backend module "art" does not define a 
"Newalbum" class. ('module' object has no attribute 'Hook').
But of course it defined. 
And the strangeness is only begins. When I put debug statement in the place 
where imagestore trying to get my model it prints proper module (already 
imported) and proper class name (string). But! dir(mod)print only variables 
appeared before "from imagestore.models.bases.album import BaseAlbum" in 
above example only "models". Why? What I don't know about importing modules?
I already tried to install it in many awkward combinations of settings 
properties, versions of django (and required apps), app_label and so on. It 
creates tables, when I inherit Newalbum from typical models.Model, but this 
models hasn't any BaseClass' behaviour.
So, what I'm doing wrong?

-- 
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/-/QkgsxcYMoz0J.
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: weird behaviour of forms in render_to_response

[ihomest...@gmail.com]

On Mar 14, 12:08 am, ihome  wrote:
> Hi,
>
> I am using the latest django development version and have some problem
> with the render_to_response to render a template. Here is a short
> snippet:
>
>     return render_to_response('index.html', {
>         'form': form,
>         'ops' : ops,
>       })
>
> form comes from a newly defined data form inherited from forms.Form.
> For one line in my template index.html:
>
> 
>
> The rendered html page looks like:
>
>  value="100" id="id_p" />" />

One typo: it is generated as:

" />

which is not what I expect the code to behave. Any idea of what is
wrong?

>
> Not sure why the render_to_response want to generate a whole  type="text" name="p" value="100" id="id_p" /> for my {{  form.v }}
>
> Do I miss anything here? I do not want this pre-defined behaviour. Is
> there a way to turn it off. For ops dict type, everything works as
> expected.
>
> Thanks.
--~--~-~--~~~---~--~~
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: weird behaviour of forms in render_to_response

[Malcolm Tredinnick]

On Fri, 2009-03-13 at 21:08 -0700, ihome wrote:
> Hi,
> 
> I am using the latest django development version and have some problem
> with the render_to_response to render a template. Here is a short
> snippet:
> 
> return render_to_response('index.html', {
> 'form': form,
> 'ops' : ops,
>   })
> 
> form comes from a newly defined data form inherited from forms.Form.
> For one line in my template index.html:
> 
> 
> 
> The rendered html page looks like:
> 
>  value="100" id="id_p" />" />
> 
> Not sure why the render_to_response want to generate a whole  type="text" name="p" value="100" id="id_p" /> for my {{  form.v }}

Because form.v is a BoundField instance that knows how to render itself.
The idea is that you only include {{ form.v }} in the template and it
renders nicely in 90% of cases.

> 
> Do I miss anything here? 
> I do not want this pre-defined behaviour.

Then don't do that.

You'll need to extract individual elements from inside the BoundField
instance and render those individually. Except, you can't do that solely
from templates at the moment, because getting the correct value for the
field isn't possible. You would need to write a custom template filter
to extract the necessary information.

That will be changed in Django 1.1 -- track ticket #10427 if you're
interested in following progress there.

Regards,
Malcolm


>  Is
> there a way to turn it off. For ops dict type, everything works as
> expected.
> 
> Thanks.
> 
> 
> > 
> 


--~--~-~--~~~---~--~~
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: weird behaviour of forms in render_to_response

[ihomest...@gmail.com]

thanks for the info. I'll track the ticket. for now, I just convert
the values to a dict and pass it over to my template.

On Mar 14, 12:27 am, Malcolm Tredinnick 
wrote:
> On Fri, 2009-03-13 at 21:08 -0700, ihome wrote:
> > Hi,
>
> > I am using the latest django development version and have some problem
> > with the render_to_response to render a template. Here is a short
> > snippet:
>
> >     return render_to_response('index.html', {
> >         'form': form,
> >         'ops' : ops,
> >       })
>
> > form comes from a newly defined data form inherited from forms.Form.
> > For one line in my template index.html:
>
> > 
>
> > The rendered html page looks like:
>
> >  > value="100" id="id_p" />" />
>
> > Not sure why the render_to_response want to generate a whole  > type="text" name="p" value="100" id="id_p" /> for my {{  form.v }}
>
> Because form.v is a BoundField instance that knows how to render itself.
> The idea is that you only include {{ form.v }} in the template and it
> renders nicely in 90% of cases.
>
>
>
> > Do I miss anything here?
> > I do not want this pre-defined behaviour.
>
> Then don't do that.
>
> You'll need to extract individual elements from inside the BoundField
> instance and render those individually. Except, you can't do that solely
> from templates at the moment, because getting the correct value for the
> field isn't possible. You would need to write a custom template filter
> to extract the necessary information.
>
> That will be changed in Django 1.1 -- track ticket #10427 if you're
> interested in following progress there.
>
> Regards,
> Malcolm
>
> >  Is
> > there a way to turn it off. For ops dict type, everything works as
> > expected.
>
> > Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Custom Save and calculating totals - weird behaviour

[Alfonso]

Discovered a weird bug in my custom save method for a model.  Setup is
a simple invoice model linked to multiple invoice order models (fk to
invoice) and the invoice model holds data like total number of units
of ordered... i.e.

Invoice order 1:
2 x X DVD @$9.99
Invoice order 2:
5 x Y DVD @$9.99

Invoice:
Total units: 7

So to get that invoice total I have a custom save method:

def save(self):
  # Grab total invoice units
  units = 0
  for item in self.customer_invoice_orders.all():
units += item.quantity
  self.invoice_units = units
  super(CustomerInvoice, self).save()

This is all set up in admin with invoice order inlines so the admin
user can edit and add to related invoice orders.

I thought it all works fine but if I adjust the quantity figure in an
inline invoice order and hit save the new total in the parent invoice
doesn't get updated, only gets updated if I hit save and continue
first, then save again.

I'm sure it's something very elementary I'm overlooking

Thanks



--~--~-~--~~~---~--~~
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: Custom Save and calculating totals - weird behaviour

[Daniel Roseman]

On May 13, 11:28 am, Alfonso  wrote:
> Discovered a weird bug in my custom save method for a model.  Setup is
> a simple invoice model linked to multiple invoice order models (fk to
> invoice) and the invoice model holds data like total number of units
> of ordered... i.e.
>
> Invoice order 1:
> 2 x X DVD @$9.99
> Invoice order 2:
> 5 x Y DVD @$9.99
>
> Invoice:
> Total units: 7
>
> So to get that invoice total I have a custom save method:
>
> def save(self):
>   # Grab total invoice units
>   units = 0
>   for item in self.customer_invoice_orders.all():
>     units += item.quantity
>   self.invoice_units = units
>   super(CustomerInvoice, self).save()
>
> This is all set up in admin with invoice order inlines so the admin
> user can edit and add to related invoice orders.
>
> I thought it all works fine but if I adjust the quantity figure in an
> inline invoice order and hit save the new total in the parent invoice
> doesn't get updated, only gets updated if I hit save and continue
> first, then save again.
>
> I'm sure it's something very elementary I'm overlooking
>
> Thanks

I expect this is happening because inlines are saved *after* the
parent model. So, think what happens: you click save, and Django first
goes to save the invoice. It goes to the database to get all the
existing InvoiceOrders, but only finds the old values because the new
ones haven't been saved yet. Only then does it go and save the
inlines. But the second time you click save, the new values in the
inlines have already been saved, so it picks them up, and properly
updates your parent model.

I can't think of a very good way of solving this. One possibility
might be to put the update code in the form, rather than the model.
--
DR.
--~--~-~--~~~---~--~~
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: Custom Save and calculating totals - weird behaviour

[Alfonso]

Daniel,

I think that's what is happening too.  I'm wondering if the save issue
has something to do with my Invoice admin class:
class CustomerInvoiceAdmin(admin.ModelAdmin):
inlines = [
CustomerInvoiceOrderInline,
]
def save_formset(self, request, form, formset, change):
instances = formset.save(commit=False)
units = 0
for instance in instances:
instance.save()
formset.save()

Thanks

On May 13, 12:13 pm, Daniel Roseman 
wrote:
> On May 13, 11:28 am, Alfonso  wrote:
>
>
>
> > Discovered a weird bug in my custom save method for a model.  Setup is
> > a simple invoice model linked to multiple invoice order models (fk to
> > invoice) and the invoice model holds data like total number of units
> > of ordered... i.e.
>
> > Invoice order 1:
> > 2 x X DVD @$9.99
> > Invoice order 2:
> > 5 x Y DVD @$9.99
>
> > Invoice:
> > Total units: 7
>
> > So to get that invoice total I have a custom save method:
>
> > def save(self):
> >   # Grab total invoice units
> >   units = 0
> >   for item in self.customer_invoice_orders.all():
> >     units += item.quantity
> >   self.invoice_units = units
> >   super(CustomerInvoice, self).save()
>
> > This is all set up in admin with invoice order inlines so the admin
> > user can edit and add to related invoice orders.
>
> > I thought it all works fine but if I adjust the quantity figure in an
> > inline invoice order and hit save the new total in the parent invoice
> > doesn't get updated, only gets updated if I hit save and continue
> > first, then save again.
>
> > I'm sure it's something very elementary I'm overlooking
>
> > Thanks
>
> I expect this is happening because inlines are saved *after* the
> parent model. So, think what happens: you click save, and Django first
> goes to save the invoice. It goes to the database to get all the
> existing InvoiceOrders, but only finds the old values because the new
> ones haven't been saved yet. Only then does it go and save the
> inlines. But the second time you click save, the new values in the
> inlines have already been saved, so it picks them up, and properly
> updates your parent model.
>
> I can't think of a very good way of solving this. One possibility
> might be to put the update code in the form, rather than the model.
> --
> DR.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Weird behaviour in Django logging (Django 1.3 RC)

[Edwin]

I'm getting a strange behaviour when setting up logging. Here's my
logging configuration:

LOGGING =
{
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'admin_configuration': {
'format': '%(asctime)s %(levelname)s %(category)s %
(sub_category)s %(type_id)s %(message)s',
'datefmt': LOG_DATE_FORMAT,
},
},
'handlers': {
'admin_console': {
'level':'DEBUG',
'class':'logging.StreamHandler',
'formatter': 'admin_configuration'
},
'db': {
'level':'DEBUG',
'class':'apps.history.handlers.DatabaseHandler',
'formatter': 'admin_configuration'
},
},
'loggers': {
'db_logger': {
'handlers': [ 'admin_console', 'db' ],
'level': 'DEBUG',
'propagate': False,
},
}
}

I then created a Database log handler and the log record will be
created using signals (e.g. on model save/delete) because I'm trying
to keep track of model changes.  As you can see from my config, the
logger has 2 handlers, 1 for DB and 1 for stdout (stream handler).

I use the logger this way:

logging.getLogger('db_logger').log(level, msg, extra=extras)

where extras are extra attributes I'm passing to the logger.

Now the weird thing is, when I change the order of 'handlers'
definition under 'db_logger' to ['db', 'admin_console'], the logger
raises this error:
LogRecord instance has no attribute 'asctime'

After checking the record instance, 'message' attribute is generated
either, but all of my extra attributes are there.
The same error happens if I remove 'admin_console' handler. The only
way I can get the logger to work is that the handler must be in the
original order:  'handlers': [ 'admin_console', 'db' ]


Any idea why this is happening??


THanks.

-- 
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: Weird behaviour in Django logging (Django 1.3 RC)

[Russell Keith-Magee]

On Sat, Mar 5, 2011 at 10:41 AM, Edwin  wrote:
> I'm getting a strange behaviour when setting up logging. Here's my
> logging configuration:
>
> LOGGING =
> {
>    'version': 1,
>    'disable_existing_loggers': True,
>    'formatters': {
>        'admin_configuration': {
>            'format': '%(asctime)s %(levelname)s %(category)s %
> (sub_category)s %(type_id)s %(message)s',
>            'datefmt': LOG_DATE_FORMAT,
>        },
>    },
>    'handlers': {
>        'admin_console': {
>            'level':'DEBUG',
>            'class':'logging.StreamHandler',
>            'formatter': 'admin_configuration'
>        },
>        'db': {
>            'level':'DEBUG',
>            'class':'apps.history.handlers.DatabaseHandler',
>            'formatter': 'admin_configuration'
>        },
>    },
>    'loggers': {
>        'db_logger': {
>            'handlers': [ 'admin_console', 'db' ],
>            'level': 'DEBUG',
>            'propagate': False,
>        },
>    }
> }
>
> I then created a Database log handler and the log record will be
> created using signals (e.g. on model save/delete) because I'm trying
> to keep track of model changes.  As you can see from my config, the
> logger has 2 handlers, 1 for DB and 1 for stdout (stream handler).
>
> I use the logger this way:
>
> logging.getLogger('db_logger').log(level, msg, extra=extras)
>
> where extras are extra attributes I'm passing to the logger.
>
> Now the weird thing is, when I change the order of 'handlers'
> definition under 'db_logger' to ['db', 'admin_console'], the logger
> raises this error:
> LogRecord instance has no attribute 'asctime'
>
> After checking the record instance, 'message' attribute is generated
> either, but all of my extra attributes are there.
> The same error happens if I remove 'admin_console' handler. The only
> way I can get the logger to work is that the handler must be in the
> original order:  'handlers': [ 'admin_console', 'db' ]
>
>
> Any idea why this is happening??

It's difficult to say. If I had to guess, I'd say there was something
unusual about your db logger. However, without seeing explicit stack
traces or sample code, that's about the best I can offer.

Yours,
Russ Magee %-)

-- 
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: Weird behaviour in Django logging (Django 1.3 RC)

[Edwin]

Sorry I wasn't clear enough. Here's the stack trace:

Traceback:
File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/
base.py" in get_response
  89. response = middleware_method(request)
File "/home/user/projects/django/../django/common/middleware.py" in
process_request
  27. return login(request, **defaults)
File "/usr/local/lib/python2.6/dist-packages/django/utils/
decorators.py" in _wrapped_view
  93. response = view_func(request, *args,
**kwargs)
File "/usr/local/lib/python2.6/dist-packages/django/views/decorators/
cache.py" in _wrapped_view_func
  79. response = view_func(request, *args, **kwargs)
File "/home/user/projects/django/../django/apps/django_extra_auth/
views.py" in login
  57. auth_login(request, form.get_user())
File "/usr/local/lib/python2.6/dist-packages/django/contrib/auth/
__init__.py" in login
  85. user_logged_in.send(sender=user.__class__, request=request,
user=user)
File "/usr/local/lib/python2.6/dist-packages/django/dispatch/
dispatcher.py" in send
  172. response = receiver(signal=self, sender=sender,
**named)
File "/usr/local/lib/python2.6/dist-packages/django/contrib/auth/
models.py" in update_last_login
  50. user.save()
File "/usr/local/lib/python2.6/dist-packages/django/db/models/base.py"
in save
  460. self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
File "/usr/local/lib/python2.6/dist-packages/django/db/models/base.py"
in save_base
  570. created=(not record_exists), raw=raw,
using=using)
File "/usr/local/lib/python2.6/dist-packages/django/dispatch/
dispatcher.py" in send
  172. response = receiver(signal=self, sender=sender,
**named)
File "/home/user/projects/django/apps/history/audit.py" in
post_save_handler
  102. logging.log_to_db(logging.INFO, msg, log_type)
File "/home/user/projects/django/apps/history/__init__.py" in
log_to_db
  61. db_logger.log(level, msg, extra=extras)
File "/usr/lib/python2.6/logging/__init__.py" in log
  1119. self._log(level, msg, args, **kwargs)
File "/usr/lib/python2.6/logging/__init__.py" in _log
  1173. self.handle(record)
File "/usr/lib/python2.6/logging/__init__.py" in handle
  1183. self.callHandlers(record)
File "/usr/lib/python2.6/logging/__init__.py" in callHandlers
  1220. hdlr.handle(record)
File "/usr/lib/python2.6/logging/__init__.py" in handle
  679. self.emit(record)
File "/home/user/projects/django/apps/history/handlers.py" in emit
  11. timestamp = datetime.strptime(record.asctime,
settings.LOG_DATE_FORMAT)


Also, I have a wrapper to call db_logger, which you can see from the
stacktrace:
def log_to_db(self, level, msg, log_type, extra={}):
db_logger = logging.getLogger('db_logger')
extras = {
'category': log_type.category.name,
'sub_category': log_type.sub_category.name,
'type_id': log_type.type_id,
}
extras.update(extra)
db_logger.log(level, msg, extra=extras)


My DB Handler looks like this:

class DatabaseHandler(logging.Handler):
def emit(self, record):
user = getattr(record, 'user', None)
category = getattr(record, 'category', None)
sub_category = getattr(record, 'sub_category', None)
type_id = getattr(record, 'type_id', None)
timestamp = datetime.strptime(record.asctime,
settings.LOG_DATE_FORMAT)
from history.models import LogRecord
LogRecord.objects.create(timestamp=timestamp,
level=record.levelname,
category=category, sub_category=sub_category,
type_id=type_id,
message=record.message, user=user)


Thanks again.

On Mar 5, 10:59 pm, Russell Keith-Magee 
wrote:
> On Sat, Mar 5, 2011 at 10:41 AM, Edwin  wrote:
> > I'm getting a strange behaviour when setting up logging. Here's my
> > logging configuration:
>
> > LOGGING =
> > {
> >    'version': 1,
> >    'disable_existing_loggers': True,
> >    'formatters': {
> >        'admin_configuration': {
> >            'format': '%(asctime)s %(levelname)s %(category)s %
> > (sub_category)s %(type_id)s %(message)s',
> >            'datefmt': LOG_DATE_FORMAT,
> >        },
> >    },
> >    'handlers': {
> >        'admin_console': {
> >            'level':'DEBUG',
> >            'class':'logging.StreamHandler',
> >            'formatter': 'admin_configuration'
> >        },
> >        'db': {
> >            'level':'DEBUG',
> >            'class':'apps.history.handlers.DatabaseHandler',
> >            'formatter': 'admin_configuration'
> >        },
> >    },
> >    'loggers': {
> >        'db_logger': {
> >            'handlers': [ 'admin_console', 'db' ],
> >            'level': 'DEBUG',
> >            'propagate': False,
> >        },
> >    }
> > }
>
> > I then created a Database log handler and the log record will be
> > created using signals (e.g.

Re: Weird behaviour in Django logging (Django 1.3 RC)

[Edwin]

I've had help from SO:
http://stackoverflow.com/questions/5249265/strange-behaviour-in-django-logging-django-1-3-rc/5250829#5250829

The solution is simply to explicitly call self.format(record) on my
emit() method under DatabaseHandler.

Hope this helps whoever face a similar problem.


-Edwin

On Mar 7, 8:58 am, Edwin  wrote:
> Sorry I wasn't clear enough. Here's the stack trace:
>
> Traceback:
> File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/
> base.py" in get_response
>   89.                     response = middleware_method(request)
> File "/home/user/projects/django/../django/common/middleware.py" in
> process_request
>   27.             return login(request, **defaults)
> File "/usr/local/lib/python2.6/dist-packages/django/utils/
> decorators.py" in _wrapped_view
>   93.                     response = view_func(request, *args,
> **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/django/views/decorators/
> cache.py" in _wrapped_view_func
>   79.         response = view_func(request, *args, **kwargs)
> File "/home/user/projects/django/../django/apps/django_extra_auth/
> views.py" in login
>   57.             auth_login(request, form.get_user())
> File "/usr/local/lib/python2.6/dist-packages/django/contrib/auth/
> __init__.py" in login
>   85.     user_logged_in.send(sender=user.__class__, request=request,
> user=user)
> File "/usr/local/lib/python2.6/dist-packages/django/dispatch/
> dispatcher.py" in send
>   172.             response = receiver(signal=self, sender=sender,
> **named)
> File "/usr/local/lib/python2.6/dist-packages/django/contrib/auth/
> models.py" in update_last_login
>   50.     user.save()
> File "/usr/local/lib/python2.6/dist-packages/django/db/models/base.py"
> in save
>   460.         self.save_base(using=using, force_insert=force_insert,
> force_update=force_update)
> File "/usr/local/lib/python2.6/dist-packages/django/db/models/base.py"
> in save_base
>   570.                 created=(not record_exists), raw=raw,
> using=using)
> File "/usr/local/lib/python2.6/dist-packages/django/dispatch/
> dispatcher.py" in send
>   172.             response = receiver(signal=self, sender=sender,
> **named)
> File "/home/user/projects/django/apps/history/audit.py" in
> post_save_handler
>   102.             logging.log_to_db(logging.INFO, msg, log_type)
> File "/home/user/projects/django/apps/history/__init__.py" in
> log_to_db
>   61.         db_logger.log(level, msg, extra=extras)
> File "/usr/lib/python2.6/logging/__init__.py" in log
>   1119.             self._log(level, msg, args, **kwargs)
> File "/usr/lib/python2.6/logging/__init__.py" in _log
>   1173.         self.handle(record)
> File "/usr/lib/python2.6/logging/__init__.py" in handle
>   1183.             self.callHandlers(record)
> File "/usr/lib/python2.6/logging/__init__.py" in callHandlers
>   1220.                     hdlr.handle(record)
> File "/usr/lib/python2.6/logging/__init__.py" in handle
>   679.                 self.emit(record)
> File "/home/user/projects/django/apps/history/handlers.py" in emit
>   11.         timestamp = datetime.strptime(record.asctime,
> settings.LOG_DATE_FORMAT)
>
> Also, I have a wrapper to call db_logger, which you can see from the
> stacktrace:
>     def log_to_db(self, level, msg, log_type, extra={}):
>         db_logger = logging.getLogger('db_logger')
>         extras = {
>             'category': log_type.category.name,
>             'sub_category': log_type.sub_category.name,
>             'type_id': log_type.type_id,
>         }
>         extras.update(extra)
>         db_logger.log(level, msg, extra=extras)
>
> My DB Handler looks like this:
>
> class DatabaseHandler(logging.Handler):
>     def emit(self, record):
>         user = getattr(record, 'user', None)
>         category = getattr(record, 'category', None)
>         sub_category = getattr(record, 'sub_category', None)
>         type_id = getattr(record, 'type_id', None)
>         timestamp = datetime.strptime(record.asctime,
> settings.LOG_DATE_FORMAT)
>         from history.models import LogRecord
>         LogRecord.objects.create(timestamp=timestamp,
> level=record.levelname,
>             category=category, sub_category=sub_category,
> type_id=type_id,
>             message=record.message, user=user)
>
> Thanks again.
>
> On Mar 5, 10:59 pm, Russell Keith-Magee 
> wrote:
>
> > On Sat, Mar 5, 2011 at 10:41 AM, Edwin  wrote:
> > > I'm getting a strange behaviour when setting up logging. Here's my
> > > logging configuration:
>
> > > LOGGING =
> > > {
> > >    'version': 1,
> > >    'disable_existing_loggers': True,
> > >    'formatters': {
> > >        'admin_configuration': {
> > >            'format': '%(asctime)s %(levelname)s %(category)s %
> > > (sub_category)s %(type_id)s %(message)s',
> > >            'datefmt': LOG_DATE_FORMAT,
> > >        },
> > >    },
> > >    'handlers': {
> > >        'admin_console': {
> > >            'level':'DEBUG',
> > >            'class':'logging.StreamHandler',
> >