Well, the discussion has people saying explicitly "propose a patch /
solution and we'll talk"... as well as others saying "I think this is a
good idea".
So I'd suggest you go for it, and jump on IRC #django-dev (freenode
network) to help.
--
Curtis
On 9 February 2015 at 13:21, Bob Remeika wrot
Yeah I think so although I don't know enough about it to know for sure.
I'm hoping to come up with something rough and then get a little help from
people that know better.
On Sunday, February 8, 2015 at 5:24:28 PM UTC-8, Curtis Maloney wrote:
>
> Certainly sounds useful, and the research seems
Sorry for the belated reply, Andrew and Curtis.
You're both right that the "bug" was just a case of makemigrations
resolving dependency issues and my misunderstanding of that fact.
To test whether this was a bug or just makemigrations splitting up the
migration, I had created a separate app wit
Certainly sounds useful, and the research seems to suggest all (most?) of
the major backends support it.
--
C
On 9 February 2015 at 11:26, Bob Remeika wrote:
> Hi,
>
> I'm new to django and python in general but I've been a programmer for a
> while now.
>
> I was interested in trying to contri
Hi,
I'm new to django and python in general but I've been a programmer for a
while now.
I was interested in trying to contribute to django in order to learn how to
navigate the internals a little better and I had my eye on this ticket
because I might actually need this functionality.
https://
Indeed, Django can make many migrations for an initial set if it needs them
to de-circularise dependencies (e.g. two models with foreign keys pointing
at each other - it splits one of their FKs into a second migration).
Andrew
On Sun, Feb 8, 2015 at 11:17 PM, Curtis Maloney
wrote:
> Could you p
Hi Andriy,
If we're going down this path, I can't think of any reason we wouldn't
target ever available aggregate. It doesn't need to be all in one patch/PR
- in fact, I'd suggest that unless the implementations are particularly
intertwined, one patch per aggregate (or aggregate group - e.g., all
Could you provide details about what sort of field you added, please?
I have seen cases where migrations will create two separate migrations for
an initial.
--
Curtis
On 9 February 2015 at 10:11, Yo-Yo Ma wrote:
> Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before
> thi
Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before
this writing), I created a model with a "name" field, then created a
migration for it. Moments after, I added an "age" field to the model,
deleted the 0001_initial.py migration, deleted __pycache__ directories in
my enti
The general reaction seems to be a yes if we can work out the kinks, so I
went ahead and created a ticket: https://code.djangoproject.com/ticket/24305
@Aron That's a good question. One option would be to lock certain fields,
so that they can't be changed if they are an integral part of the model
Hi,
I mentioned on the Django User Mailing List that the interaction of
ValidationError, mark_safe, and ugettext was not what I expected.
https://groups.google.com/d/topic/django-users/Soik095MTaI/discussion
Succinctly, the two versions of clean_slug below behave differently, when they
11 matches
Mail list logo
