Re: Deprecating psycopg 1

+1 to removing the psycopg1 backend. I was just wondering if it was ever going to happen earlier today when I was creating example settings files for running the tests, and got tired of typing 'postgresql_psycopg2'. Even getting psycopg1 installed is a small PITA on any modern Linux system.

Re: An issue with ticket system

On Sat, Sep 19, 2009 at 1:10 PM, Carl Meyer wrote: > Specifically, if you're obsessive about avoiding minor breakages, you > can try to avoid the "No newline at end of file" marker in your diffs; > pretty sure that's what causes Trac to choke. What version of Trac is

Re: Deprecating psycopg 1

On Sat, Dec 12, 2009 at 6:36 PM, Jerome Leclanche wrote: > I'm guessing it's the standard way to do things and this may be a bit > offtopic but still, out of curiousity, since the PendingDepWarning is > not visible by default doesn't this actually give the users just the >

Re: Ticket #399 -- bigint support

In my very first Django app I ran into the int limitation and my app wouldn't work. It was quite confusing for a newbie Django user, as every other toolkit and database I have ever used supported long integers. My app integrates with Twitter, and it was the id field of tweets from Twitter that

Re: Deprecating psycopg 1

I'm guessing it's the standard way to do things and this may be a bit offtopic but still, out of curiousity, since the PendingDepWarning is not visible by default doesn't this actually give the users just the illusion of more time to fix their code? Django releases are, from what I can see,

Re: Deprecating psycopg 1

On Sun, Dec 13, 2009 at 8:13 AM, Jerome Leclanche wrote: > +1 from me too on the timeline, but why the PendingDeprecationWarning? > I don't see the point, there isnt exactly a limit to how long > something can be deprecated. PendingDeprecationWarning lets us introduce the

Re: Deprecating psycopg 1

On Sun, Dec 13, 2009 at 8:02 AM, Jacob Kaplan-Moss wrote: > Hi folks -- > > I'd like to start the process of deprecating and removing support for > psycopg 1. Why? > > * psycopg 2 is better in every way. > * psycopg 1 hasn't been updated since October 2005; it's basically a

Re: Deprecating psycopg 1

+1 from me too on the timeline, but why the PendingDeprecationWarning? I don't see the point, there isnt exactly a limit to how long something can be deprecated. J. Leclanche / Adys On Sat, Dec 12, 2009 at 6:04 PM, Alex Gaynor wrote: > On Sat, Dec 12, 2009 at 7:02 PM,

Re: Deprecating psycopg 1

On Sat, Dec 12, 2009 at 7:02 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > I'd like to start the process of deprecating and removing support for > psycopg 1. Why? > > * psycopg 2 is better in every way. > * psycopg 1 hasn't been updated since October 2005; it's basically a

Deprecating psycopg 1

Hi folks -- I'd like to start the process of deprecating and removing support for psycopg 1. Why? * psycopg 2 is better in every way. * psycopg 1 hasn't been updated since October 2005; it's basically a dead end. * I don't know anyone using it in production. * For the couple-three people who

Re: What do people think about the get_absolute_url proposal?

Mike Malone wrote: > On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee > wrote: >> 4. I share Mike's concern about using settings.SITE_ID to determine >> the current host, but I'm not sure I have any suggestions on how we >> could practically use request, short of

Re: Ticket #12171

On Sat, Dec 12, 2009 at 5:34 PM, ab wrote: > or because the Django project thinks it's supporting a backend that > actually no one is paying attention to. Probably this. psycopg 1 hasn't been updated since October 2005; I can't recall anyone I know who's still using it.

Ticket #12171

I think I should bring this ticket up before 1.2 is released http://code.djangoproject.com/ticket/12171. Unless I'm doing something wrong (highly possible), get_or_create is broken with the "postgresql" db backend. This would be a pretty serious problem, either because the backend lacks core

Re: Ticket #3349 patch review

On Sat, Dec 12, 2009 at 4:18 PM, ab wrote: > I'd like some opinions on the existing patch for > http://code.djangoproject.com/ticket/3349. > This ticket ("If an ImportError occurs within some loaders a rather > confusing exception is raised") seeks to address the difficulty

Ticket #3349 patch review

I'd like some opinions on the existing patch for http://code.djangoproject.com/ticket/3349. This ticket ("If an ImportError occurs within some loaders a rather confusing exception is raised") seeks to address the difficulty of debugging ImportErrors raised in template tag library. The cause of

Re: Buildbot failure

Hi Jacob, On Mon, Oct 26, 2009 at 11:05 PM, Jacob Kaplan-Moss wrote: > I've more or less given up and am working on pony-build instead. Watch > this space. Do you want any help with this? I'd be happy to if it'd be useful. I found your script at

Re: Ticket #399 -- bigint support

Gosh... copy paste was a bit fast... ti was http://code.google.com/p/django-iptocountry/ Manu -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from

Re: Ticket #399 -- bigint support

Hi, I have just subscribed and do not know how much power I'll have through my post... :) but just to let you know: I ran into the need of a bigint on postgresql installing (and refactoring a bit) http://code.google.com/p/django-countryip/ I changed the integer to bigint directly in the base