On Thu, 2010-12-23 at 11:46 -0500, Karen Tracey wrote:
> Well, great, status wasn't 200 but what was it? That's information I'd
> really rather get by default, so I much prefer assertEquals, which
> tells me:
>
> Traceback (most recent call last):
> File [snipped]
> self.assertEqual(res.stat
On Dec 23, 2:55 pm, Christophe Pettus wrote:
> On Dec 23, 2010, at 11:35 AM, Eric wrote:
>
> > a) To fix this, one must identify the sequences that are not correct.
> > I scoured pg_catalog and friends and cannot identify where PostgreSQL
> > exposes the link between the "id" and sequence columns.
Hi,
Most django-admin commands that connect to the database are never
closing the database connection. This can be an issue because:
1) it will clutter the logs with errors like:
(when using postgresql)
2010-12-11 13:09:04 EST LOG: could not receive data from client:
Connection reset by peer
2
On Dec 23, 2010, at 11:35 AM, Eric wrote:
> a) To fix this, one must identify the sequences that are not correct.
> I scoured pg_catalog and friends and cannot identify where PostgreSQL
> exposes the link between the "id" and sequence columns.
Just FYI, it's stored in pg_depend.
--
-- Christophe
We recently started the test and upgrade process to bring our large
Django applications more up to date with 1.3 to help test new things.
We found that http://code.djangoproject.com/changeset/13363 introduced
backwards incompatible changes.
Previously, using PostgreSQL, it was possible to take a m
Currently ListView.paginate_queryset discriminates whether the resulting
queryset is paginated or not in order to return a page_obj into the context
(http://code.djangoproject.com/browser/django/trunk/django/views/generic/list.py?rev=14864#L51).
If there is only one page, 'page_obj' is set to Non
On 23 December 2010 17:56, Ian Clelland wrote:
> On Thu, Dec 23, 2010 at 8:46 AM, Karen Tracey wrote:
>> On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant wrote:
>> Perhaps it is not a problem when using bare asserts for this purpose, but I
>> have grown to dislike asserts in testcases because they gi
My team has adopted the convention of prepending "Sanity:" to the message of
any assertion whose purpose is to verify that things are set up correctly
for the
'main act' assertions. This helps us cut through the 'something is broken,
but it's
not here' noise when a change causes a bunch of tests t
On Thu, Dec 23, 2010 at 8:46 AM, Karen Tracey wrote:
> On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant wrote:
> Perhaps it is not a problem when using bare asserts for this purpose, but I
> have grown to dislike asserts in testcases because they give so little
> information. For example, I am working
On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant wrote:
> Hi all,
>
> This is a question of test code style.
>
> In tests in my own projects, I use both the Python 'assert' statement
> and the unittest TestCase.assert* methods, with the following
> distinction:
>
> * The 'assert' statement is used to
On Thu, Dec 23, 2010 at 5:44 AM, Luke Plant wrote:
> Hi all,
>
> This is a question of test code style.
>
> In tests in my own projects, I use both the Python 'assert' statement
> and the unittest TestCase.assert* methods, with the following
> distinction:
>
> * The 'assert' statement is used to m
Thanks for the notification!
On Dec 23, 2:24 pm, Ramiro Morales wrote:
> Klaas,
>
> On Thu, Dec 23, 2010 at 7:43 AM, Klaas van Schelven
>
> wrote:
> > Hi all,
>
> > Thanks for checking in 14910!
>
> > Could anyone take a serious look at
> >http://code.djangoproject.com/ticket/14924
>
> > It has
Hi,
On Wed, Dec 22, 2010 at 10:40:06PM -0600, James Bennett wrote:
> Tonight we've released Django 1.3 beta 1, as well as Django 1.2.4 and
> Django 1.1.3 to correct a pair of security issues.
FYI, the new releases have not been tagged in svn.
Thanks,
Forest
--
Forest Bond
http://www.alittletooq
Hi all,
This is a question of test code style.
In tests in my own projects, I use both the Python 'assert' statement
and the unittest TestCase.assert* methods, with the following
distinction:
* The 'assert' statement is used to make assertions about the
assumptions built in to *this* bit of code
Klaas,
On Thu, Dec 23, 2010 at 7:43 AM, Klaas van Schelven
wrote:
> Hi all,
>
> Thanks for checking in 14910!
>
> Could anyone take a serious look at
> http://code.djangoproject.com/ticket/14924
>
> It has a test that proves the problem and a relatively simple patch.
>
> I'm doing a lot of "app o
Hi all,
Thanks for checking in 14910!
Could anyone take a serious look at
http://code.djangoproject.com/ticket/14924
It has a test that proves the problem and a relatively simple patch.
I'm doing a lot of "app overriding" and this bug is extremely annoying
in that case. It would be great if the
16 matches
Mail list logo
