On Sat, May 14, 2011 at 11:16 PM, br wrote:
> Pretty new to django. While {% comment %} {% endcomment %} isn't
> that cumbersome, its cumbersome enough compared to that I
> find myself using html comments more often than I should (given that
> these comments will end up
Pretty new to django. While {% comment %} {% endcomment %} isn't
that cumbersome, its cumbersome enough compared to that I
find myself using html comments more often than I should (given that
these comments will end up in my output), largely because i'm too lazy
to type out the full django
This is a slightly confusing set of messages to be forwarded to
django-devs - please remember that django-devs has over 6000 subscribers
who probably don't want to have to put together fragments of a private
conversation!
But the original message from Jody was sent 2 weeks ago to django-devs,
and
Hey Jody/Django Devs,
A friend of mine saw this go by and forwarded on to me.
testfixtures is actively maintained and, while I don't use filters
myself, I consider it a bug that this doesn't work as you expect!
Can you email me a sample unit test that doesn't work properly and I'll
get this
On 12/05/11 12:41, Michal Petrucha wrote:
> 1) Leave out the ``unique`` option and live with ``unique_together``.
>This would pribably imply also leaving out ``db_index``, otherwise
>the API would be a complete mess.
>
> 2) Allow ``CompositeField.unique`` but also keep
> > 2) Allow ``CompositeField.unique`` but also keep ``unique_together``.
> >The problem I see with this approach is that there would be two
> >quite different ways to achieve the same effect.
>
> I agree with Javier - I favor option 2. In my mind, although the final
> result at the
On 05/14/2011 04:26 PM, Jonas H. wrote:
I believe there's no generalized way of creating databases in Django
now, so that would have to be added.
s/creating/copying/
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group,
How about caching the test databases? The database state could be cached
after model setup (which takes some time if you've got lots of them) +
initial data fixture setup, and after the setup for each test case
(fixtures + setUp() method).
So, in the best case, no database setup is required
On Fri, May 13, 2011 at 09:01:19AM -0700, onelson wrote:
> I'm not that familiar with GFK's and how they work in django, but I just
> wanted to check...
> Will we have (non-generic) FK support for this, or is that another
> can-o-worms that won't get touched for some time?
Adding support for
Thanks Mathieu,
I already knew this library, however I wanted to have a quick implementation
that doesn't use classytags or any other thirdclass library. But thanks to
your link I looked in the documentation of sekizai again and saw the
restrictions page [1]. And after having a look at the my
10 matches
Mail list logo