I actually think this would be super useful if we can make it make sense
(HEAD~ with merges..). "Undo the migration I just did" is a common
operation in development.
M
On 11 Mar 2016 2:18 p.m., "Joakim Saario" wrote:
> You can always have a y/N-question to limit these cases. Though, I think
> th
I guess you could! I'm not as familiar with the Transforms API, but it
looks like it would work too.
On Wed, Mar 30, 2016 at 6:17 PM, Shai Berger wrote:
> On Tuesday 29 March 2016 05:07:14 Stephen J. Butler wrote:
> > Why not do this in the database? Create a view with an extra column that
> is
On Thursday 31 March 2016 02:03:26 Florian Apolloner wrote:
> Having a new field seems overkill to me -- a new validation routine which
> is less strict is something we should be able to do without backward compat
> considerations.
Strictly speaking, the new method is not less strict. It does forb
On Tuesday 29 March 2016 05:07:14 Stephen J. Butler wrote:
> Why not do this in the database? Create a view with an extra column that is
> called "field_dttxt" that is to_char(field, 'Mon DD, '). Then add this
> as a field to Django and let it use the normal Q lookups.
>
Why would you need to
On Tuesday 29 March 2016 13:19:01 Anssi Kääriäinen wrote:
>
> Personally I think we should just rename the method to fast_create()
> and allow it to fall back to single row at time behavior. This way you
> could safely call it for any objects on any database and know the
> results will be OK. I do
Having a new field seems overkill to me -- a new validation routine which
is less strict is something we should be able to do without backward compat
considerations. The reasoning for this is easy: As long as it is not proven
that the current regex covers only valid addresses a less strict valid
On Wednesday 30 March 2016 15:45:23 Tim Graham wrote:
> How did you imagine the deprecation cycle working? Do you want Django to
> raise a warning saying that the regular expression is changing and provide
> a temporary setting or something to opt-in to the simpler validation?
>
Yes, that's one o
What's the plan for formsets with extra?
I could see the required only getting applied to the first min forms but I'm
not sure there is an actual workable case there. It seems like it will get too
messy with adding and deleting at the same time.
If can_delete is false and extra is 0, it seems
How did you imagine the deprecation cycle working? Do you want Django to
raise a warning saying that the regular expression is changing and provide
a temporary setting or something to opt-in to the simpler validation?
On Saturday, March 26, 2016 at 5:25:04 AM UTC-4, Shai Berger wrote:
>
> On Tu
