I'm certainly in favour of not reinventing the wheel here. As a side note,
I would love to have the javascript slugify functionality easily usable
outside the admin.
On 20 December 2014 at 04:51, Berker Peksağ wrote:
>
> While I'm working on #3729 [1], I had to update current regexes to
> match u
While I'm working on #3729 [1], I had to update current regexes to
match unicode codepoints. Unfortunately, JavaScript has no proper
support for unicode character classes, so writing unicode aware regex
is a bit difficult: http://stackoverflow.com/a/280762
I would like to add XRegexp to django.con
For what it's worth, for my team, it just comes down to speed (so a single
in-memory migration per app is great, and so is speeding up migrations
overall).
I have a stopwatch at my desk and did some quick (unscientific) timing of
creating the test DB for my own project:
*Without migrations* (MIGR
Hi All,
Totally a shot in the dark here, but would allow_migrate work in this case?
https://docs.djangoproject.com/en/dev/topics/db/multi-db/#allow_migrate
Collin
On Friday, December 19, 2014 2:04:37 PM UTC-5, Carl Meyer wrote:
>
> On 12/19/2014 11:59 AM, Marcin Nowak wrote:
> >
> >
> > On F
On 12/19/2014 11:59 AM, Marcin Nowak wrote:
>
>
> On Friday, December 19, 2014 12:19:11 AM UTC+1, Shai Berger wrote:
>>
>>
>> As far as I understood, Marcin wants to treat *all* models as unmanaged;
>> there
>> are no managed models to reference the unmanaged ones.
>>
>
> I would like to disa
On Friday, December 19, 2014 12:19:11 AM UTC+1, Shai Berger wrote:
>
>
> As far as I understood, Marcin wants to treat *all* models as unmanaged;
> there
> are no managed models to reference the unmanaged ones.
>
I would like to disable/remove/kick-off built-in migration mechanism. :)
If may
Yes. Claude has worked on the deprecation in
https://github.com/django/django/pull/3220 but it requires adding more
migrations to our test suite and he noted that each migration we add to
Django's test suite adds up to ~3.5 seconds to the run time of the test
suite. He also worked on some speed
Hi Tim,
I can have a look, but I can't be certain about hitting any deadlines. I do
want to get that deprecation in, though...
Did you want it with a view to us being able to drop that in for tests
rather than making migrations for every test app, I presume?
Andrew
On Fri, Dec 19, 2014 at 3:06
Andrew, I've thought of something similar to the in-memory migrations idea
you've proposed. It would be great not to have to add and maintain
migrations for all of the apps in Django's test suite. Do you think you
might be able to investigate this solution in the next month or so before
1.8 alp
I agree that migrations are slower than syncdb - that's perhaps the only
thing worse about them - but the reason we plan to deprecate the other
methods is code simplicity; migrations does not share almost any code with
the old DatabaseCreation backends, and if we don't deprecate it we're going
to e
10 matches
Mail list logo
