ansaction decorators, but I'm more confident that I know
what's going on with that so I'm preparing a ticket about it with a
patch right now).
--
Sean Legassick
sean.legass...@gmail.com
--~--~-~--~~~---~--~~
You received this message because
this wouldn't undo (such as changing table structures or altering the
content types data). Obviously it will help if by 'horrible things'
you mean inserting broken or unwanted data into your model tables, but
it strikes me that the solution to that is to fix the code that'
subsequent
TestCase tests will be operating on a test db with any modifications
made by the TransactionTestCase test still in place, and thus
potentially failing.
So am I missing something or should this be changed?
Sean
--
Sean Legassick
sean.legass...@gmail.com
--~--~-~--~---
On 10 Sep 2008, at 15:38, Brian Rosner wrote:
>> I think that the commit=False (or save=False in FieldFile.save() )
>> should not do the save to the storage backend.
>
> Agreed. I have been considering treating FileFields the same as
> many-to-many fields when commit=False in a ModelForm. In the
On 10 Sep 2008, at 09:49, Simon Willison wrote:
> I think we should maintain a list of doctypes - there really aren't
> that many: xhtml1, xhtml1trans, xhtml1frameset, html4, html4trans,
> html4frameset, xhtml11 and html5 should cover everything.
There's also xhtml-mp, wml and chtml for mobile a
t with the gis
branch and PostGIS so I can try out the patch there and see what
happens).
--
Sean Legassick
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" grou
On 10 May 2008, at 14:47, Sebastian Noack wrote:
> You can still do model.objects.update(foo=42) with my patch, because
> of 42 is casted to a LiteralExpr under the hood. I could even make it
> possible to do model.objects.update(foo=CurrentExpr() + 42). But there
> is no way to enable model.obje