On Oct 2, 5:42 pm, "Sean O'Connor" wrote:
> To be honest this seems like something which would be a lot of work with
> relatively little gain. For this to work raw() would need to change from a
> relatively simple bit of code which doesn't need to touch all of the
2009/10/2 Javier Guerra
>
>
> - if there's no 'failure record' run all
> - if there's some record, first test those that have failed the last time
> - if they still fail, stop there
> - if there's no further failures, rerun the whole set
>
>
+1, that sounds like a good
> - if there's no 'failure record' run all
> - if there's some record, first test those that have failed the last time
> - if they still fail, stop there
> - if there's no further failures, rerun the whole set
That's a pretty cool idea. I haven't seen this kind of behavior
before but it
Hi,
I need to change the normal behavior for icontains filter option (for
django-firebird backend implementation).
For icontains filter, django add automatically an '%' but, for case
insensitive search, firebird uses the CONTAINING statement which
doesn't need %
Then, the question is, which
On Fri, Oct 2, 2009 at 5:10 AM, Harro wrote:
>
> Sounds like a bad plan, what if by fixing the failed test you break
> another one?
while testing, when i found some not-obvious test failure and i have
to run the test repeatedly, i try to run just this one until it
passes.
To be honest this seems like something which would be a lot of work with
relatively little gain. For this to work raw() would need to change from a
relatively simple bit of code which doesn't need to touch all of the complex
query code in the ORM to a complex bit of code which needs to deeply
On Fri, Oct 2, 2009 at 7:35 PM, mrts wrote:
>
> Wishful thinking follows.
>
> It would be awesome if one could mix ordinary QuerySet methods
> with raw() (or, rather, raw_extra(), see below for that).
While I can see what you're aiming at here, I'm not really a fan of the
On Tue, Sep 29, 2009 at 6:54 AM, SeanOC wrote:
>
> Hello All,
>
> During the Djangocon sprints I started to work on a patch which would
> add a nicer interface for dealing with raw SQL queries. While there I
> talked to RKM about where it should fit into the ORM API
Sounds like a bad plan, what if by fixing the failed test you break
another one?
On Sep 29, 6:03 pm, Rob Madole wrote:
> I've been using nose for our tests, and one of the features that I
> really like is the ability to run the tests again but filter only the
> ones that
On Oct 2, 12:09 pm, Ned Batchelder wrote:
> I would think the same logic applies to Django. Nose needs to work with
> lots of different projects, so they can't own the Django details, since
> by that logic they'd also own the TurboGears logic, the Pylons logic,
> the
Wishful thinking follows.
It would be awesome if one could mix ordinary QuerySet methods
with raw() (or, rather, raw_extra(), see below for that).
Assuming the following models:
class Foo(models.Model):
name = models.CharField(max_length=255)
class FooDates(models.Model):
foo =
Hi,
I want to subclass a db field (CharField), but in the to_python()
method I need the value (which is given) and the model instance (which is
missing).
I looked at the source of django/db/models/fields/subclassing.py:
Rob Madole wrote:
>> From the point of view of encouraging the usage of nose, either would
>> work fine. I think this is fits in to the conversation at DjangoCon
>> about how we should go about encouraging Django users to explore the
>> wider Python ecosystem. The important thing is that we can
13 matches
Mail list logo