weird "can't adapt" error

[Sandro Dentella]

Hi,

I'm meeting a weird problem in a django application.
It works w/o any problem from my pc connecting remotely to my customer's
apache but is not working inside the lan.

I'm connecting from firefox/ubuntu they're connecting from firefox/XP.

the weird part is that:

1. they have being working w/o probelms for 10 days and no modifications
where made

2. the error complains "can't adapt" as if trying to insert wrong types
into the db, but the error trace shows the values are correct

3. a restart of apache fixes the problem

4. this is the second time the error happens...

Any hints?
TIA
sandro
*:-)

[sandro dentella]

On 26 Set, 12:59, Sandro Dentella <san...@e-den.it> wrote:
> Hi,
>
> I'm meeting a weird problem in a django application.
> It works w/o any problem from my pc connecting remotely to my customer's
> apache but is not working inside the lan.
>
> I'm connecting from firefox/ubuntu they're connecting from firefox/XP.
>
> the weird part is that:
>
> 1. they have being working w/o probelms for 10 days and no modifications
> where made
>

> 2. the error complains "can'tadapt" as if trying to insert wrong types

> into the db, but the error trace shows the values are correct
>
> 3. a restart of apache fixes the problem
>
> 4. this is the second time the error happens...
>
> Any hints?
> TIA
> sandro
> *:-)

Hi,

once again I stumble into this problem. This time I gathered some
more
info so I describe them.

I try to insert a record it fails from a Windows pc with Firefox
(and
IE). It works from linux (firefox or galeon).

When it fails the error message is "can't adapt" but

1. the params in the log are:
('2007-10-26 08:50:03.651993', '2007-10-26 08:50:03.652039', 1, 17,
'2007-10-26', u'2', Decimal("100"), 'h', u'prova in fi'

2. from my linux box I print params before a *working* insert and I
get:
['2007-10-26 09:17:44.744656', '2007-10-26 09:17:44.744682', 1, 17,
'2007-10-26', u'2', Decimal("100"), 'h', u'prova']

Not realy different!!!!

3. When it fails the database is not hit. Db is postgres and I
switched on
statement log on every log:

log_min_duration_statement = 0

4. If I restart apache the error is fixed

I'm running mod_wsgi

What should I do, next time it happens to better investigate. It's
already
happened 4 times in 2 months and I cannot just accept it...

Thanks for any possible help

sandro
*:-)

the insert statement that worked follows:

INSERT INTO
"timereport_report" ("date_create","date_last_modify","status","user_id","date","job_id","qty","unit","description")
VALUES ('2007-10-26 10:09:07.721575','2007-10-26 10:09:07.721619',
1,17,'2007-10-26','2',100,'h','prova in fi2')

[Jarek Zgoda]

I just started receiving the same problem when I try to save an object
that has non-ASCII values in char field (the values are all properly
decoded to unicode)> This seems related to psycopg2 backend, as I do
not observe such behaviour on my dev server with sqlite3 backend. The
model is similar to:

class Label(models.Model):
title = models.CharField(max_length=200, unique=True)

the code that leads to exception is like:

t = 'żołędzie'.decode('utf-8')
label = Label(title=t)
label.save()

The traceback from ipython:

/home/zgoda/www/zgodowie/blog/models.py in save(self)
42 if not self.slug:
43 self.slug = slughifi(self.title)
---> 44 super(Label, self).save()
45
46

/home/zgoda/www/.python/lib/python2.4/site-packages/django/db/models/
base.py in save(self, raw)
257 cursor.execute("INSERT INTO %s (%s) VALUES
(%s)" % \
258 (qn(self._meta.db_table),
','.join(field_names),
--> 259 ','.join(placeholders)), db_values)
260 else:
261 # Create a new record with defaults for
everything.

ProgrammingError: can't adapt

I use SVN trunk rev. 6702.

[Sandro Dentella]

On Tue, Nov 20, 2007 at 01:17:50AM -0800, Jarek Zgoda wrote:
>
> I just started receiving the same problem when I try to save an object
> that has non-ASCII values in char field (the values are all properly
> decoded to unicode)> This seems related to psycopg2 backend, as I do
> not observe such behaviour on my dev server with sqlite3 backend. The
> model is similar to:
>
> class Label(models.Model):
> title = models.CharField(max_length=200, unique=True)
>
> the code that leads to exception is like:
>
> t = 'żołędzie'.decode('utf-8')
> label = Label(title=t)
> label.save()
>
> The traceback from ipython:

what makes my case different from this is that the same code creates
probelm from one browser and not from another in a repeatable way. Both are
firefox but running on linux (no probelma) or windows (can't adapt).

I didn't solve it, but it's a month it doesn't happen again...

sandro
*:-)

[Jarek Zgoda]

The problem in my case seems to be strictly related to psycopg2
backend. I tried with psycopg and it does not happens.

Should I file a ticket?

[Jeremy Dunck]

On Oct 26, 2007 2:47 AM, sandro dentella <san...@e-den.it> wrote:
...

>
> once again I stumble into this problem. This time I gathered some
> more
> info so I describe them.

http://groups.google.com/group/django-users/browse_thread/thread/091aa6c088f6c090

I understand you're running wsgi rather than mod_python, but if you're
running multiple interpreters, you'll still have the problem discussed
there.

[Jeremy Dunck]

"Can't adapt" is quite a vague error that psycopg2 issues.

Your issue is (apparently) something to do with encoding, and that's
different than Sandro's issue.

Please include more information, especially if you do decide to file a
ticket. I can't help with the info given so far...

[Jarek Zgoda]

OK, filed a ticket, but really I do not have any idea as what might be
"usable information" in this case, just copied what I posted here.
What makes me thinking there's a bug somewhere, is that the code works
for psycopg and sqlite3, but fails for psycopg2.

On 20 Lis, 22:06, "Jeremy Dunck" <jdu...@gmail.com> wrote:
> "Can't adapt" is quite a vague error that psycopg2 issues.
>
> Your issue is (apparently) something to do with encoding, and that's
> different than Sandro's issue.
>
> Please include more information, especially if you do decide to file a
> ticket. I can't help with the info given so far...
>

[thomasb...@gmail.com]

This is just a shot in the dark, but I just solved a similar problem
that just popped up for me.

I noticed that you are creating slugs for your object near where the
error happens. I had the exact same error happen when creating
slugified names. It turned out that I was calling the built-in
slugify() filter in django.template.defaultfilters. This code changed
significantly as a part of the autoescaping code that was checked in
starting with r6671. I didn't investigate all the way to finding out
what part of the filter code was causing the issue, I just solved it
by taking the regex logic out of the filter and putting it in my own
slugify() method.

I was running off the trunk (r6708) with psycopg2.

Hope this helps,
-Thomas

[Michael]

Thanks Thomas... your shot in the dark hit it's mark for me :)

I was suffering the same "can't adapt" psycopg2 error (worked fine
with sqlite), but it was due to the exact reason you stated.

Although your solution is probably better in the long run, another
solution is to simply convert the result of slugify into a normal
string (as slugify now returns a django.utils.safestring.SafeUnicode
object and the psycopg2 cursor cannot convert this to a string). For
example:

>>> from django.template import defaultfilters

>>> self.group_slug = defaultfilters.slugify(self.name)

becomes:
>>> self.group_slug = str(defaultfilters.slugify(self.name))

Thanks again! It's been causing me headaches...

On Nov 21, 2:55 pm, "thomasbohmb...@gmail.com"

[Sandro Dentella]

On Tue, Nov 20, 2007 at 03:04:09PM -0600, Jeremy Dunck wrote:
>
> On Oct 26, 2007 2:47 AM, sandro dentella <san...@e-den.it> wrote:
> ...
> >
> > once again I stumble into this problem. This time I gathered some
> > more
> > info so I describe them.
>
> http://groups.google.com/group/django-users/browse_thread/thread/091aa6c088f6c090
>
> I understand you're running wsgi rather than mod_python, but if you're

correct

> running multiple interpreters, you'll still have the problem discussed
> there.

but that server only has 1 django project (and nothing more). In other
servers I have many concurrent django process but probably I'm not using
decimal.

The link you reported are very interesting but do not explain me why I'm
meeting probelms from all machines on the LAN and not from mine (or from
Windows and not from Linux, but these conditions overlap...).

sandro
*:-)

[Jarek Zgoda]

Michael napisał(a):

> Thanks Thomas... your shot in the dark hit it's mark for me :)
>
> I was suffering the same "can't adapt" psycopg2 error (worked fine
> with sqlite), but it was due to the exact reason you stated.
>
> Although your solution is probably better in the long run, another
> solution is to simply convert the result of slugify into a normal
> string (as slugify now returns a django.utils.safestring.SafeUnicode
> object and the psycopg2 cursor cannot convert this to a string). For
> example:
>
>>>> from django.template import defaultfilters
>
>>>> self.group_slug = defaultfilters.slugify(self.name)
>
> becomes:
>>>> self.group_slug = str(defaultfilters.slugify(self.name))
>
> Thanks again! It's been causing me headaches...

I'll try this. I tried to do a force_unicode() on slughifi output, but
without luck. I'll try with str() instead.

--
Jarek Zgoda
Skype: jzgoda | GTalk: zg...@jabber.aster.pl | voice: +48228430101

"We read Knuth so you don't have to." (Tim Peters)