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, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> 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
>
> On Nov 20, 4:17 pm, Jarek Zgoda <[EMAIL PROTECTED]> wrote:
>
> > 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" <[EMAIL PROTECTED]> 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...
>
> > > On Nov 20, 2007 2:55 PM, Jarek Zgoda <[EMAIL PROTECTED]> wrote:
>
> > > > 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?
>
> > > > On 20 Lis, 10:17, Jarek Zgoda <[EMAIL PROTECTED]> 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:
>
> > > > > /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.
>
> > > > > On 26 Paź, 09:47, sandro dentella <[EMAIL PROTECTED]> wrote:
>
> > > > > > On 26 Set, 12:59, Sandro Dentella <[EMAIL PROTECTED]> wrote:
>
> > > > > > > Hi,
>
> > > > > > >   I'm meeting a weird problem in adjangoapplication.
> > > > > > >   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')
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to