On Wed, Nov 30, 2011 at 2:26 PM, Adrian Holovaty wrote:
> Just to be clear, how would you get the "diff" of what's changed?
> Would it automatically change the fixture files after you close the
> shell session? Or would that be up to you?
Yes, I was thinking of catching SystemExit, KeyboardI
On Wed, Nov 30, 2011 at 11:30 PM, Aymeric Augustin
wrote:
...
> In my current job we're using https://github.com/rbarrois/factory_boy, we've
> dropped all but the most trivial fixtures (sites, languages, an admin user),
> and we haven't looked back.
Nifty, thanks.
--
You received this message
On 30 nov. 2011, at 23:26, Adrian Holovaty wrote:
> On Wed, Nov 30, 2011 at 4:22 PM, Jeremy Dunck wrote:
>> 1) expand on the testing guide to present fixtures as one option
>> for test data and point out the options to script fixture generation
>> or avoiding fixtures in favor of TestCase-calle
It might just be a crazy idea .. but sometimes I wish something like
this existed:
https://gist.github.com/1414209
On Nov 30, 10:36 pm, Ned Batchelder wrote:
> On 11/30/2011 5:22 PM, Jeremy Dunck wrote:
>
>
>
>
>
>
>
> > Hi all,
> > I've got a codebase with a fair bit of fixtures and have bee
On 11/30/2011 5:22 PM, Jeremy Dunck wrote:
Hi all,
I've got a codebase with a fair bit of fixtures and have been
experiencing some pain around it. One of the pains is migrating the
format of fixtures when a schema change occurs.
I posted a thread to south-users to discuss the idea of ad
As there seemed to be some hesitation about how best to proceed with
my recent work on the features/py3k branch, I've merged the features/
py3k branch into the default branch of my repo at
https://bitbucket.org/vinay.sajip/django/
and fixed most of the resulting issues. Current summary results ar
On Wed, Nov 30, 2011 at 4:22 PM, Jeremy Dunck wrote:
> 1) expand on the testing guide to present fixtures as one option
> for test data and point out the options to script fixture generation
> or avoiding fixtures in favor of TestCase-called generation,
> discussing tradeoffs in the approaches
On Wed, Nov 30, 2011 at 5:22 PM, Jeremy Dunck wrote:
> Hi all,
> I've got a codebase with a fair bit of fixtures and have been
> experiencing some pain around it. One of the pains is migrating the
> format of fixtures when a schema change occurs.
>
> I posted a thread to south-users to discuss
Hi all,
I've got a codebase with a fair bit of fixtures and have been
experiencing some pain around it. One of the pains is migrating the
format of fixtures when a schema change occurs.
I posted a thread to south-users to discuss the idea of adding a
feature to aid applying migrations to fixt
"""
/me runs off to go correct Wikipedia ;)
I checked the Wikipedia article on Primary Key first, and didn't see that, but
I did note this:
A table can have at most one primary key, but more than one unique key. A
primary key is a combination of columns which uniquely specify a row. It is a
sp
On Wed, Nov 30, 2011 at 1:15 PM, Ian Clelland wrote:
> On Wed, Nov 30, 2011 at 12:40 PM, Kääriäinen Anssi <
> anssi.kaariai...@thl.fi> wrote:
>
>> """
>> Is this referring exclusively to natural, or user-specified primary key
>> columns? Despite Luke's reference to nullable primary keys (are thes
On Wed, Nov 30, 2011 at 12:40 PM, Kääriäinen Anssi
wrote:
>
> """
> Is this referring exclusively to natural, or user-specified primary key
> columns? Despite Luke's reference to nullable primary keys (are these even
> allowed by SQL?), a common idiom for copying objects is this:
> """
>
> Not all
"""
Is this referring exclusively to natural, or user-specified primary key
columns? Despite Luke's reference to nullable primary keys (are these even
allowed by SQL?), a common idiom for copying objects is this:
"""
Not allowed by SQL specification, but many databases do allow them (source
wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/29/2011 11:32 PM, Anssi Kääriäinen wrote:
> I should not have said that this would be a good optimization, and
> used the possible optimizations wording. I haven't got any performance
> problems when using delete in 1.3. So from my point
> of vie
On Wed, Nov 30, 2011 at 4:26 AM, Kääriäinen Anssi
wrote:
> """
> > The reason for doing the deprecation now is that it would be nice that
> > this behavior is already removed when multicolumn primary keys are
> > introduced into Django.
> >
> > There is a ticket related to this: #2259.
>
> Here is
"""
> The reason for doing the deprecation now is that it would be nice that
> this behavior is already removed when multicolumn primary keys are
> introduced into Django.
>
> There is a ticket related to this: #2259.
Here is another that could be helped by this change, depending on
implementation
On 30/11/11 07:13, Anssi Kääriäinen wrote:
> The reason for doing the deprecation now is that it would be nice that
> this behavior is already removed when multicolumn primary keys are
> introduced into Django.
>
> There is a ticket related to this: #2259.
Here is another that could be helped by
17 matches
Mail list logo
