Re: Choosing migration with relative syntax

2016-03-30 Thread Marc Tamlyn 
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
> this is a problem as it is right now too, because you can always do a typo.
>
> /Joakim
>
> Den fredag 11 mars 2016 kl. 14:06:42 UTC+1 skrev Markus Holtermann:
>>
>> Hi Joakim,
>>
>> thank you for your proposal.
>>
>> I don't think this is a good idea because you can easily accidentally
>> undo too many migrations which would inevitably will result in data loss.
>> You don't have the data loss problem in Git as you can always recover by
>> using `git reflog` to go back and e.g. undo an incorrect rebase. However,
>> when you remove a field from a database table the data is pretty much lost.
>>
>> Cheers,
>>
>> /Markus
>>
>> On Friday, March 11, 2016 at 11:39:53 PM UTC+11, Joakim Saario wrote:
>>>
>>> Hello!
>>>
>>> Today if you just need to unmigrate the *n* migrations before the last
>>> one you would
>>> typically run `migrate  --list` and then `migrate 
>>> ` where
>>> `migration_name` is the migration you want to roll back to.
>>>
>>> To reduce the steps of this procedure i think it would be nice to
>>> introduce
>>> a syntax similar to how commits in for example git works. I.e `git show
>>> HEAD^`
>>> for the previous commit and `git show HEAD~2` for the one before that.
>>> It would also be good to support the `git show (^+)|(~\d)`
>>> variant
>>> of this to be able to choose the origin.
>>>
>>> For this to work good for the normal case, there need to be a magic word
>>> that maps to the latest migration available and/or the latest applied
>>> migration.
>>>
>>> I can clearly see a use case for this as I can imagine that the most
>>> common
>>> operation besides applying all unmigrated migrations is to roll back *n*
>>> migrations.
>>>
>>> Does this sounds like a good idea?
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/46b90e2f-e14d-41c9-8ac8-f7758e3a3d46%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EjGUM3P4e6GBFAdSHTnJoiXO1OEUAKJPY1RMyT0hkZAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: An idea for Q filter objects

2016-03-30 Thread Stephen J. Butler 
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
> > 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 create a view? Can't you use a Transform?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD4ANxWL8XT6pySuUD3NZmOTdQFk5cHKjoQ9wVKUDpGWcePW%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

2016-03-30 Thread Shai Berger 
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 forbid things 
the current validation lets through (mostly wrt unicode domains, IIRC).

> The reasoning for this is easy: As long as it is not proven
> that the current regex covers only valid addresses a less strict validation
> is not harming anyone. Especially since even if an email address is
> technically valid, it does not mean that is actually exists -- so you will
> have to send an email to verify the address anyways…
> 

But we could, considering this, just call it a "backwards incompatible 
change".

Shai.

Re: An idea for Q filter objects

2016-03-30 Thread Shai Berger 
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 create a view? Can't you use a Transform?

Re: bulk_create for multi table inheritance support

2016-03-30 Thread Shai Berger 
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 don't see much point in throwing errors when
> batch insert isn't possible. If batch insert isn't possible, the user
> needs to insert the values one row at a time in any case.
> 

I beg to differ. fast_create() as you described will be suitable for some 
users, but if creating 2000 records is going to require 2000 database 
roundtrips, I'd appreciate a way to be told about it already when I'm testing 
with 2. I could have other options to create the records (perhaps not using 
the ORM at all), or I could decide early that the backend is unsuitable for my 
needs.

For some optimizations, it is OK to just drop them if you can't do them. But 
with bulk_create we could be talking about differences of orders of magnitude. 
It seems to me that with that premise, the decision that it's ok to drop the 
optimization should be explicit, and not Django's default.

My 2 cents,
Shai.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

2016-03-30 Thread Shai Berger 
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 option; another is to define a HTML5EmailField (or a better 
name) that uses the simpler validation, and warn that EmailField is going to 
turn into an alias of that -- so that each EmailField in the project is 
handled separately.

Also, I'm not sure it's possible to have the warning produced by a check; but 
if it is, that would be preferable.

Shai.

Re: Value of tightening URLValidator/EmailValidator regular expressions?

2016-03-30 Thread Tim Graham 
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 Tuesday 15 March 2016 04:51:50 Markus Holtermann wrote: 
>
> > 
> > WRT the backwards compatibility issues: 
> > 
> > 2) You're not able to submit an email address that does not pass the new 
> > validator but the old one. --> Unlikely, but when the new field is of 
> > type="email" your rather modern browser will tell you before Django 
> > anyway 
> > 
>
> While this is correct, in many of your rather modern web applications 
> Django 
> does not own the front-end, and for web services, a relevant front end 
> doesn't 
> even necessarily exist. 
>
> So the backward-incompatibility is not horrible, but it exists and needs 
> to be 
> mitigated by a deprecation cycle. 
>
> Shai 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4f821407-4ebb-47ec-9a78-d17b3cf5014a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.