Good point about SQLite. I considered SQLite, but went with hacking
the test code in the end. My production environment uses MySql, so my
test environment should as well.
For example, I just uncovered a bug in my code that has to do with
database interactions. This bug may or may not show up when
On Tue, Dec 8, 2009 at 6:43 AM, Simon Willison wrote:
> This made it to the 1.2 feature list:
>
> http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
>
> If we want this in 1.2, it could be as simple as merging the get_url /
> get_url_path methods in to the base Model class, rolling a few u
On Tue, Dec 8, 2009 at 10:49 PM, Jeremy Dunck wrote:
> On Tue, Dec 8, 2009 at 8:38 PM, Luke Plant wrote:
>> On Wednesday 09 December 2009 01:52:48 Jeremy Dunck wrote:
> ...
>>> You could also inspect the item to see if it's an instance of the
>>> .model; if not, fast path False.
>>>
>>> Which lea
On Tue, Dec 8, 2009 at 8:38 PM, Luke Plant wrote:
> On Wednesday 09 December 2009 01:52:48 Jeremy Dunck wrote:
...
>> You could also inspect the item to see if it's an instance of the
>> .model; if not, fast path False.
>>
>> Which leads to a question of edge-case semantics -- "1 in qs"
>> checki
On Wednesday 09 December 2009 01:52:48 Jeremy Dunck wrote:
> On Tue, Dec 8, 2009 at 7:22 PM, Luke Plant
> wrote: ...
>
> > However, it could be slightly more efficient in some cases,
> > because the entire QuerySet._result_cache does not necessarily
> > need to be filled - we can stop if we find
2009/12/9 Martin Omander :
> Hi all,
>
> How about letting Django users run unit tests without creating a new
> test database?
>
> To use Django's built-in unit test harness, you have to have database
> creation privileges. Not all web hosts give users those privileges.
> For example, Webfaction, a
On Tue, Dec 8, 2009 at 7:22 PM, Luke Plant wrote:
...
> However, it could be slightly more efficient in some cases, because
> the entire QuerySet._result_cache does not necessarily need to be
> filled - we can stop if we find a match, saving us the work of
> building Model objects that might not b
On Tue, Dec 8, 2009 at 8:22 PM, Luke Plant wrote:
> Hi all,
>
> I discovered that QuerySet supports the 'in' operator:
>
> myset = Articles.objects.filter(foo=bar)
> if someobject in myset:
> # etc.
>
> The Python docs I could find imply (but don't state) that if there is
> no __contains__(
Hi all,
I discovered that QuerySet supports the 'in' operator:
myset = Articles.objects.filter(foo=bar)
if someobject in myset:
# etc.
The Python docs I could find imply (but don't state) that if there is
no __contains__() method, but there is __getitem__(), then
__getitem__() is cal
Hi all,
I've now addressed everything in Russell's last e-mail, I think, so I
think I'm pretty much good to go, apart from:
1) my last change rewrote a lot of IfParser, which was the heart of
the patch. That means it probably needs looking at again! On the other
hand, the new implementation is
Hi all,
How about letting Django users run unit tests without creating a new
test database?
To use Django's built-in unit test harness, you have to have database
creation privileges. Not all web hosts give users those privileges.
For example, Webfaction, an excellent commercial Django host by all
Hi Russell,
I was away and arrived back too late for this to matter, but for the
sake of the archives, I just had a couple of comments:
> Module-based configuration:
> ---
>
> * The aesthetic of user-configuration options is cleaner because
> configuration items are sho
On Wed, Dec 9, 2009 at 12:55 AM, Jacob Kaplan-Moss wrote:
> Hi Russ --
>
> This is looking pretty great; I'm a big fan of this approach. I've
> looked through the places I've needed to work around this problem with
> serializers, and your fix would work in every case, so I think you
> nailed it.
>
I'd much rather have this information come from the current request
vs. coming from settings. Relying on the Site is particularly
annoying. I like the implementation of build_absolute_uri() in
django.http.HttpRequest. The hard part is getting the request object
to a place where it's usable by model
On Wed, 2009-11-25 at 10:52 -0800, Rob Hudson wrote:
> I like the solution proposed on ticket 10587:
> http://code.djangoproject.com/ticket/10587
>
> Basically, it proposes that timezones are handled analogous to how
> Unicode is handled -- that is, everything within Django boundaries is
> treated
On Tue, Dec 8, 2009 at 12:56 PM, Alex Gaynor wrote:
> This line of reasoning makes 0 sense IMO. Your argument is people
> provide sub-par patches because they think trunk moves too quickly,
> and a committer will need to rewrite it anyways.
OK, I declare bikeshed.
I'll run the experiment a
On Tue, Dec 8, 2009 at 1:47 PM, mrts wrote:
>> On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote:
>> > Sorry to hear that. The document you linked is a start, but I'm a bit
>> > concerned by this goal:
>> > "to keep the main integration branch as stable as the official trunk
>> > so that it c
> On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote:
> > Sorry to hear that. The document you linked is a start, but I'm a bit
> > concerned by this goal:
> > "to keep the main integration branch as stable as the official trunk
> > so that it can be used in actual deployments"
>
> > My concern
On Tue, Dec 8, 2009 at 11:40 AM, Alex Gaynor wrote:
...
> Personally I think merge queues ignore where the real work is.
> Applying a patch (as a diff, or pulling from another repo myself) is a
> trivial amount of work, and the number of times I have had actual
> conflicts between 2 patches that w
On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote:
> On Tue, Dec 8, 2009 at 11:27 AM, mrts wrote:
> ...
>> I have thought about the process a bit and even wrote some
>> helper code.
>>
>> Unfortunately I fell ill and haven't fully recovered (and am
>> therefore horribly off-schedule with my wor
On Tue, Dec 8, 2009 at 11:27 AM, mrts wrote:
...
> I have thought about the process a bit and even wrote some
> helper code.
>
> Unfortunately I fell ill and haven't fully recovered (and am
> therefore horribly off-schedule with my work), so I haven't
> had the chance to continue with the effort.
On Dec 8, 5:32 am, Russell Keith-Magee wrote:
> On Tue, Dec 8, 2009 at 11:11 AM, Tobias McNulty
> wrote:
> > On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee
> > wrote:
> >> I was thinking more of having one person at the sprint to take the
> >> role of integrator - that is, the patches stil
Hi Russ --
This is looking pretty great; I'm a big fan of this approach. I've
looked through the places I've needed to work around this problem with
serializers, and your fix would work in every case, so I think you
nailed it.
I do, however, have one wrench to throw into the works:
As it stands,
I brought this up during the 1.1 dev schedule and if I remember correctly
the response was "let's have it painted red" and it seemed like it wasn't
considered a practical problem.
The reason I think this is an issue is the same reason that I get frustrated
whenever I see a pull-style handle on a d
24 matches
Mail list logo
