It's not abusive, and we use Django daily. I looked at the QuerySet
recactoring and I honestly don't like the aggregate() stuff.
We are real people, and developers also :)
On Jul 27, 8:59 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> On 7/27/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
>
>
> > Q
That was a typo I actually just fixed.
http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyAppsAndMakingYoursPortable
Thanks for letting me know,
Sebastian
On Jul 27, 1:39 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> On Jul 27, 12:47 pm, Sebastian Macias <[EMAIL PROTECTED]>
> wro
Hi all,
Every so often we get a few tickets popping up about ReST errors in
the docs. I've just patched one (#4995) where some hideously glaring
mistakes like, say, missing a space after an asterisk, or one too few
empty lines caused nasty error messages like:
testing.txt:584: (WARNING/2) Inline
I propose we add a hook to the unit-test framework that would give
developers access to information about the underlying database queries
in a given test.
Specifically, I could see (and I currently *have*) needs for the
following assertions:
* Assert a given custom model method runs a certain, e
On 7/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> If all you want is the fixtures, why not use a unittest.TestCase, and
> put a call to management.load_data() in your TestCase.setUp() method?
I tried that and got the same problem. The setUp() method is called
before each test method of
On 7/28/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> In my case, I need django.test.TestCase because I'm using the fixtures
> framework, but I don't want the database flushes because I'm only
> using the database in a read-only fashion.
If all you want is the fixtures, why not use a unittes
On 7/28/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 7/24/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > Are there any objections to making this change?
>
> Go for it!
Cheers. Committed as #5769.
Russ %-)
--~--~-~--~~~---~--~~
You received this m
On 7/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> The database flush only happens at the start of each test if you use a
> django.test.TestCase. If you use unittest.TestCase or a doctest, no
> flush is applied.
>
> If you have a class of tests that don't touch the database backend,
> yo
On 7/27/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> QuerySet refactoring is like Django 1.0 ya? Never coming?
The Django developers are ::gasp:: real people, with real jobs and
real lives. I see this perhaps more readily than most, since a few of
them are my co-workers. Considering all the
On 7/28/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> QuerySet refactoring is like Django 1.0 ya? Never coming?
>
> We've been struggling to use the Django ORM for a long while now,
> because it has limited support for complex queries. GROUP BY is a
> nescesity. I don't see any problem with redo
On 7/28/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> class MyTestCase(TestCase):
> def testSomething(self):
> # ...
> testSomething.alters_db = False
>
> With this, the test runner would be smart enough to know *not* to
> reset the database after this test.
>
> I don't know f
On 7/24/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Are there any objections to making this change?
Go for it!
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
QuerySet refactoring is like Django 1.0 ya? Never coming?
We've been struggling to use the Django ORM for a long while now,
because it has limited support for complex queries. GROUP BY is a
nescesity. I don't see any problem with redoing the QuerySet methods,
but there's no reason to not put in w
On 7/28/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> I committed a quick patch earlier to trunk that adds group_by()
> support.
Hi David,
The idea of a 'group_by' and 'having' clause has been floated many
times before, and has been rejected in preference of an 'aggregations'
framework that pr
I noticed an issue while implementing this (could just be our
version).
When doing select={'choices': 'COUNT(...)'} It threw an error in
__set__ on the manager.add(*value) call (fields/related.py); choices
was a related_name call. It however did not error when doing
select={'choices': 'my_column'
I committed a quick patch earlier to trunk that adds group_by()
support.
I can't run the tests on trunk, as we're not quite up that far, but it
should be working.
http://code.djangoproject.com/ticket/4997#comment:1
I plan to add having=[] support to extra as well this weekend.
--~--~-
Hi all (but mostly Russell, the Test Master General :) ),
I have a significantly large set of fixture data for Django unit tests
in a work project, and the time lag in clearing and reinserting the
data between each test is getting to be frustrating. However, at the
same time, it's clearly importa
On Jul 27, 12:47 pm, Sebastian Macias <[EMAIL PROTECTED]>
wrote:
> I just added it to the wiki:
>
> http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyApp...
I don't think you meant to have the exact same directory structure for
a django project as you did for 3rd party apps, did y
I just added it to the wiki:
http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyAppsAndMakingYoursPortable
It's also available via the resources page.
http://code.djangoproject.com/wiki/DjangoResources
Best,
Sebastian Macias
On Jul 25, 11:19 am, Sebastian Macias <[EMAIL PROTEC
Access 1000's of Television Channels From All Over The World
Watch all your favorite shows on your Computer from anywhere in the
World!
Save 1000's of $$$ over many years on cable and satellite bills.
INSTANT DOWNLOAD
Learn More About it at Link below:
http://freetvonpc.50webs.com/
--~--~--
On Jul 27, 7:09 pm, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> BTW, it would be nice if the docs (docs/*.txt) could be viewed
> under the admin interface. The text to html conversion could be
> done during the request.
May I suggest this?
http://smileychris.tactful.co.nz/ramblings/django-docume
Am Freitag, 27. Juli 2007 05:10 schrieb [EMAIL PROTECTED]:
> I was thinking, for the sake of helping new users learn quicker, that
> the Django documentation could be organized a little more. In
> particular the list under "Reference"
>
> i would think a numbered list would be more suitable with 1
22 matches
Mail list logo
