Enforcing a max size for form field values read into memory (review/determination of next steps needed)

[Tim Graham]

Hi, I think I will be able to make good on my promise to give all the 
tickets that were in the review queue on last Friday a review for 1.9, 
except for this one...

https://code.djangoproject.com/ticket/21231
https://github.com/django/django/pull/3852

Mostly I am wondering if there any other frameworks that do a similar thing 
so we can at least validate that the design makes sense. 


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f52b7c48-05c8-4efa-9f6b-c18930e58642%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Tim Graham]

I think a better use of time could be to update the docs to more strongly 
recommend virtualenv and discourage the use of `sudo pip install`.

On Wednesday, September 9, 2015 at 10:17:48 AM UTC-4, Anjul Tyagi(geety) 
wrote:
>
> Thanks for all that information Nick, it helped me a lot.
>
> Yes, it will be a platform specific information but may be we can just 
> mention it in the documentation, giving the users a hint.
>
> -Anjul
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6f636ec6-f871-489c-a195-b22b4dd30a12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hide specific users from auth user model for non super users

[Florian Apolloner]

On Wednesday, September 9, 2015 at 5:42:07 PM UTC+2, Xavier Palacín Ayuso 
wrote:
>
> I need hide a super admin's users from auth user model of Django of list 
> users template for a normal users or no super admin users.
>

Hi Xavier. This mailing list is for discussing the development of 
django itself, not for discussing how to develop in django. 

For help with developing in django, please use django-users mailing 
list (and be patient - just because no-one has answered you in 6 hours 
does not mean you should kick it up to django-developers). 

Cheers 

Florian (or should I say tom since I copied directly from his previous 
answer ;))  

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7a50e03-484f-47e3-84e2-dd1417bb80ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hide specific users from auth user model for non super users

[Xavier Palacín Ayuso]

I need hide a super admin's users from auth user model of Django of list 
users template for a normal users or no super admin users.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e1c56f2b-c2ec-4314-88ad-c341d193e836%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Get current user in model signal pre_save

['Tom Evans' via Django developers (Contributions to Django itself)]

On Wed, Sep 9, 2015 at 4:11 PM, Xavier Palacín Ayuso
 wrote:
> I want to collects current user in model signal pre_save, to prevent remove
> super user permission to current super users.

Hi Xavier. This mailing list is for discussing the development of
django itself, not for discussing how to develop in django.

For help with developing in django, please use django-users mailing
list (and be patient - just because no-one has answered you in 6 hours
does not mean you should kick it up to django-developers).

Cheers

Tom

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1LmaqFniJr5gLMkfcewasCm6EW8nZjDpnMHan9jrSdndg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Get current user in model signal pre_save

[Xavier Palacín Ayuso]

I want to collects current user in model signal pre_save, to prevent remove 
super user permission to current super users.
As I have now so I can not give administrative privileges to a normal user.

from django.db.models.signals import pre_delete, pre_save, post_save
from django.dispatch.dispatcher import receiver
from django.contrib.auth.models import User
from django.core.exceptions import PermissionDenied


@receiver(pre_save, sender=User)
def save_user(sender, instance, **kwargs):
if instance._state.adding is True:
# we would need to create the object
print "Creating an object"
else:
#we are updating the object
if instance.is_superuser:
raise PermissionDenied

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1b710450-6d76-46ce-a8bf-1a0a49c55cf8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Anjul Tyagi(geety)]

Thanks for all that information Nick, it helped me a lot.

Yes, it will be a platform specific information but may be we can just 
mention it in the documentation, giving the users a hint.

-Anjul

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/84211c51-81de-4178-ab5e-cfa2d67fc880%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

To make myself clear. I don't think we need to document this as it is not a 
django error. 

It is a Python error because the module was not installed correctly.

Maybe there should be a mention of the difference for installation on 
Ubuntu (and other linux distros?). But this would be unusual for anyone 
using Windows or Mac as they won't have a default Python install and will 
often only have 1 version, so 1 pip.

- Nick.

On Wednesday, September 9, 2015 at 3:05:15 PM UTC+1, Nick Sarbicki wrote:
>
> In which case you need to install it again with *pip3*.
>
> All the defaults in Ubuntu (Python, pip etc.) are focused on 2.7, you 
> always need to append 3 if you want it to be *python3 *specific.
>
> For earlier versions of ubuntu this was because some core processes 
> required python2.7 and would call it through *python*. I think they are 
> past that with the latest release, but from memory there is a *pep* somewhere 
> which states that this should remain the standard for now.
>
> - Nick.
>
> On Wednesday, September 9, 2015 at 2:58:36 PM UTC+1, Anjul Tyagi(geety) 
> wrote:
>>
>> yes, I installed django using *pip *and not* pip3.*
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/507c7031-f5e6-46ca-b6e1-1811cc600e8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

In which case you need to install it again with *pip3*.

All the defaults in Ubuntu (Python, pip etc.) are focused on 2.7, you 
always need to append 3 if you want it to be *python3 *specific.

For earlier versions of ubuntu this was because some core processes 
required python2.7 and would call it through *python*. I think they are 
past that with the latest release, but from memory there is a *pep* somewhere 
which states that this should remain the standard for now.

- Nick.

On Wednesday, September 9, 2015 at 2:58:36 PM UTC+1, Anjul Tyagi(geety) 
wrote:
>
> yes, I installed django using *pip *and not* pip3.*
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8e361d61-ee46-4b00-8536-a1ebc0a1ac65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Anjul Tyagi(geety)]

yes, I installed django using *pip *and not* pip3.*

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4418a32f-c568-4fbd-ba8f-4685815d1fea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

Can you show us how you installed django?

More specifically, did you do 

*pip install django*

and

*pip3 install django*

As it looks like you only install django for 2.7, and not for 3.4.

- Nick.

On Wednesday, September 9, 2015 at 2:51:07 PM UTC+1, Anjul Tyagi(geety) 
wrote:
>
> Hi everyone,
>
> I am new to django and wish to address the problem which I faced during 
> the installation of django on Ubuntu 14.04.
> I had two versions of python installed before I installed django: python 
> 2.7.6 and python 3.4. I installed django as per the steps given in the 
> documentation.
> Now, 
> If I type the following on the terminal:
>
>
> *python>>>import django*
>
> It works correctly, but
>
>
> *python3>>>import django*
>
> shows the module not found error 
> .
>  
> I think we can document this inside the "verifying" section of the "Quick 
> Installation guide" part of documentation just to make sure that new users 
> don't panic seeing this error.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1eedff19-6212-4b49-8521-7889ce30dfec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL Dispatcher

[James Addison]

Marten, good to have you back in the fold. I'll leave the effort in your
hands (phew!) - as before, let me know if I can help in any way. I'm fairly
new to Django internals, so don't expect much!

I can test, however, and help with docs somewhat (based on limited
knowledge).

Cheers,
James
On Sep 9, 2015 2:52 AM, "Marten Kenbeek"  wrote:

> Hi James,
>
> Thanks for keeping this alive while I had some personal issues to sort
> out. I'll be working on this again, though I can use all the help I can
> get.
>
> As for the work that still needs to be done:
>
>- 3.1 is done, mostly as a proof-of-concept that can be found at
>https://github.com/knbk/django/tree/url_dispatcher
>- 3.2 is done. I've worked on this in separate PR's, which have all
>been merged by now.
>- 3.3:
>   - Legacy functionality has been implemented, namely through the
>   RegexPattern, LocalizedRegexPattern and LocalePrefix constraints.
>   - I've kept a lot of functional tests, and I believe the unit tests
>   have decent coverage. It would be good to have more tests, but I don't
>   think it's a necessity.
>   - Yes, pretty much all the documentation must still be written.
>   - These could be implemented pretty straight-forward in separate
>   patches after the main project has been merged.
>
> The resolver is not quite as fast as I'd hoped, especially `reverse()`.
> There are some trade-offs we can make, but we'll have to decide which are
> worth it.
> I think that is the main problem we need to tackle before we push for a
> merge.
>
> Marten
>
> Op dinsdag 25 augustus 2015 20:57:14 UTC+2 schreef Tim Graham:
>>
>> Thanks for taking this on, James. I do think it would be best to defer
>> this to Django 1.10 rather than try to rush it into Django 1.9 at this
>> point. Also, there are several URL related deprecations scheduled to
>> complete in 1.10 which should simplify things (I've started on those
>> removals here: https://github.com/django/django/pull/5143). Absent
>> another interested person, I should be able to mentor you on this during
>> the Django 1.10 release cycle (which can start once we cut the stable/1.9.x
>> branch after 1.9 alpha around September 21). In the meantime, if you want
>> take a look for some simpler tickets to tackle to get a feel for our
>> contribution process, I think that would be helpful.
>>
>> On Tuesday, August 25, 2015 at 2:25:07 PM UTC-4, James Addison wrote:
>>>
>>> In the interests of keeping the excellent work done by Marten Kenbeek
>>> (knbk on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current
>>> and moving along, I've created a new branch [2] and rebased it against
>>> current master. (I am doing this because it seems like Marten is no longer
>>> able to continue working on the effort. *If this should change or is
>>> incorrect, Marten, please let me/us know!*)
>>>
>>> To try and find how far along the project is, I've quickly compared the
>>> original GSOC outline/timeline [1] against my updated branch [2] to see
>>> what is done/remaining:
>>>
>>>- section 3.1 (Design phase) I believe was done, but am unable to
>>>find anything other than a few posts on the django-developer mailing 
>>> list - *is
>>>there a source for this?*
>>>- section 3.2 (Namespace overhaul) hasn't been addressed that I can
>>>tell - *I'd recommend dropping this as it isn't core to the effort*
>>>- Items completed in section 3.3 (Dispatcher API): 3.3.[1-4]
>>>- *Items remaining* in section 3.3: (Dispatcher API): 3.3.[5-9] -
>>>some highlights:
>>>   - re-implementing some legacy functionality for backward
>>>   compatibility (ie. RegexURLPattern)
>>>   - additional tests
>>>   - lots of documentation!
>>>   - additional resolvers (ie. scheme, sub-domain, etc)
>>>
>>>
>>>
>>> Please keep in mind that I'm mostly unfamiliar with the internals of
>>> Django core elements, so I may have easily overlooked/mistook relevant
>>> information. I'd appreciate any other review/input as well. Here is the
>>> branch comparison [3] on Github.
>>>
>>> Based on the Django 1.9 release schedule, I have doubts that this will
>>> be merged in for feature freeze, which is unfortunate. I would like to
>>> think that I am up to the task, but the URL functionality in Django is
>>> about as 'core' as it gets and I would not want to bite off more than I can
>>> chew without backup. Any thoughts on the continued viability of this
>>> effort? Is this something that someone inexperienced with Django internals
>>> should take on? If so, I'd definitely need coaching!
>>>
>>> Lastly, I want to mention that I do have a new project in which I had
>>> been using Marten's branch (and am now using my own branch [2]), and it has
>>> been functionally solid for the scheme, (sub) domain and url resolving and
>>> reversing use cases. See the the urls.py [4] from that project to whet
>>> your appetites as to the possibilities of all this. :)
>>>
>>> Pr

Proposal to document the error on trying to import django in python 3.4.

[Anjul Tyagi(geety)]

Hi everyone,

I am new to django and wish to address the problem which I faced during the 
installation of django on Ubuntu 14.04.
I had two versions of python installed before I installed django: python 
2.7.6 and python 3.4. I installed django as per the steps given in the 
documentation.
Now, 
If I type the following on the terminal:


*python>>>import django*

It works correctly, but


*python3>>>import django*

shows the module not found error 
.
 
I think we can document this inside the "verifying" section of the "Quick 
Installation guide" part of documentation just to make sure that new users 
don't panic seeing this error.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/009dba30-6461-490a-80e1-b643f75d6c11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Markus Holtermann]

On Wednesday, September 9, 2015 at 9:21:43 PM UTC+10, Shai Berger wrote:
>
>
>
> On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek  > wrote: 
> > 
> >> 
> >> The order of migrations isn't something which is local to this 
> >feature, it 
> >> is something which isn't fixed (probably by design, correct me if I'm 
> > 
> >> wrong) and if it is not "the right way" to do it, maybe it should be 
> >part 
> >> of another issue. 
> > 
> > 
> >The order of migrations within a single app is fixed. 
>
> No, actually it isn't. It is only constrained by dependencies. Merge 
> migrations do not fix it either. The only thing they do is tell the 
> warning-happy migration system : "yes, I have considered the situation here 
> and it's OK to run these two migrations in either order ". 
>
No, they do ensure some sort of deterministic behavior. Migrations are 
sorted by their fully qualified name (tuple of (app_label, migration_name)):
https://github.com/django/django/blob/master/django/db/migrations/graph.py#L64

This behavior is enough for a 3rd party app to destroy the results of your 
own migration or the other way round.

Consider a.1 <-- a.2 <-- b.1 where b.1 makes changes to the app a. When the 
author of app a add another migration a.3 (a.1 <-- a.2 <-- (a.3, b.1)) the 
resulting order in which migrations are applied will be a.1, a.2, a.3, b.1. 
However, on an existing database, a.3 will be run after b.1, resulting in a 
non-deterministic order in which migrations for the same app are being 
applied.

Consider me a strengthened -1 looking at the discussion.

If we want to have something like "project level migrations" we should 
rethink a bunch of things, but that's out of scope of the initial proposal 
of this discussion, I think.

>
> Which raises two points : 
>
> First, can we (do we want to ) handle this validation some other way, and 
> would it buy us anything? 
>
> Second, how common is Marten's misconception? Do we need to address it? 
>
>
> Shai 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. 
>

/Markus 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c0de9532-5527-4ac5-9e6c-9a3475f9c342%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Shai Berger]

On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek  
wrote:
>
>>
>> The order of migrations isn't something which is local to this
>feature, it 
>> is something which isn't fixed (probably by design, correct me if I'm
>
>> wrong) and if it is not "the right way" to do it, maybe it should be
>part 
>> of another issue.
>
>
>The order of migrations within a single app is fixed. 

No, actually it isn't. It is only constrained by dependencies. Merge migrations 
do not fix it either. The only thing they do is tell the warning-happy 
migration system : "yes, I have considered the situation here and it's OK to 
run these two migrations in either order ".

Which raises two points : 

First, can we (do we want to ) handle this validation some other way, and would 
it buy us anything? 

Second, how common is Marten's misconception? Do we need to address it?


Shai 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ADF331E4-8B2C-4F39-9AD4-5DEA0ECA5D74%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Emmanuelle Delescolle]

On Wednesday, 9 September 2015 12:29:59 UTC+2, Marten Kenbeek wrote:
>
> The order of migrations isn't something which is local to this feature, it 
>> is something which isn't fixed (probably by design, correct me if I'm 
>> wrong) and if it is not "the right way" to do it, maybe it should be part 
>> of another issue.
>
>
> The order of migrations within a single app is fixed. That means the order 
> of the operations on a single model or table is also fixed. 
> This proposition introduces a variable order to migrations that alter the 
> same model, so yeah, this issue is local to this feature. 
>

I've had the case where migration order between apps was different between 
initialized and non-initialized database which crashed the migration 
process when running on a non-initialized database when using another 
"strongly advised against" behavior in a data migration (namely importing a 
model directly).
So, since the only case where an fixed order between an "official" and a 
"non-official" leaf node is important is when using a a "strongly advised 
against" behavior, this is debatable.


> Once again, correct me if I'm wrong but the only way to have different 
>> final rendered models would be the original third-party app 
>> defining/altering a field which has already been defined/altered by your 
>> app, resulting, in regards of the current proposal, in clashing fields.
>> Creating a field which clashes with another app's field is something bad, 
>> there are nine chances out of ten that fixed migration order will not solve 
>> your overall problem: you created a field named the same as another field, 
>> except if you have a psychic connection with the original library's author 
>> you probably have a different usage for the field (however slight the 
>> difference may be) and, if you really need to upgrade that third party 
>> library, you have a whole other mess to fix than conflicting migrations so 
>> I am really wondering if this is worth the hassle.
>> If you create two models with the same meta db_table, django doesn't come 
>> to your rescue and propose a solution, it is something you shouldn't have 
>> done and now you have to deal with it. I think this "edge case" is in the 
>> same area.
>
>
> Since we're talking about unsupported, undocumented ways to change models 
> anyway (like contribute_to_class), I think altering an existing 
> field is a very legitimate reason to create a new migration. For instance, 
> many people want to increase the length of the username field on the 
> default User model, and the upcoming 1.9 release will also alter the 
> username field again, resulting in the scenario I described above. So 
> unless 
> we explicitly warn against this in the documentation, we should find a 
> suitable solution for this. 
>

Personnaly I've been talking about the case which, when running 
makemigrations, creates a migration in a third party app. There are several 
legitimate use-cases outside of contribute_to_class. Contribute_to_class is 
only one case and you have been warned against using it so a warning should 
be sufficient, shouldn't it?

I would argue that if you need a longer username, you should use a custom 
user model extending AbstractUser (which would lead to one of the 
legitimate use-cases I just mentioned), which is the recommended way of 
doing it.
To go further with your example, a fixed migration order will no solve your 
problem: to keep your existing data safe. If Django's default length for a 
username is still smaller than yours you won't be able to run the migration 
at all on an existing database (or it will truncate your existing 
usernames), so you'll have to manually fake run it on any production 
database.
To have the field length set to your custom value with a fixed order, this 
would mean you have to run your migration after the new django.contrib.auth 
one, which is not possible since your migration has probably already run on 
the production database.
(If your migration hasn't run yet on production database, simply delete it 
and re-run makmigrations, it will automatically depend on the latest 
migration for that app ;-) )
And if Django's default length for the username field is larger than your 
custom value, then your data will be safe unrelated to the order in which 
the migrations run. You may then either remove your change or re-create a 
new migration (which depends on the new django.contrib.auth migration) to 
reduce the length to whatever you want it to be if you feel it's necessary.

So, yes, I still believe fixed migration doesn't bring much to this feature.

Cheers,
Emma
 

-- 
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 a

Re: Ability to migrate other applications

[Marten Kenbeek]

>
> The order of migrations isn't something which is local to this feature, it 
> is something which isn't fixed (probably by design, correct me if I'm 
> wrong) and if it is not "the right way" to do it, maybe it should be part 
> of another issue.


The order of migrations within a single app is fixed. That means the order 
of the operations on a single model or table is also fixed. 
This proposition introduces a variable order to migrations that alter the 
same model, so yeah, this issue is local to this feature. 

Once again, correct me if I'm wrong but the only way to have different 
> final rendered models would be the original third-party app 
> defining/altering a field which has already been defined/altered by your 
> app, resulting, in regards of the current proposal, in clashing fields.
> Creating a field which clashes with another app's field is something bad, 
> there are nine chances out of ten that fixed migration order will not solve 
> your overall problem: you created a field named the same as another field, 
> except if you have a psychic connection with the original library's author 
> you probably have a different usage for the field (however slight the 
> difference may be) and, if you really need to upgrade that third party 
> library, you have a whole other mess to fix than conflicting migrations so 
> I am really wondering if this is worth the hassle.
> If you create two models with the same meta db_table, django doesn't come 
> to your rescue and propose a solution, it is something you shouldn't have 
> done and now you have to deal with it. I think this "edge case" is in the 
> same area.


Since we're talking about unsupported, undocumented ways to change models 
anyway (like contribute_to_class), I think altering an existing 
field is a very legitimate reason to create a new migration. For instance, 
many people want to increase the length of the username field on the 
default User model, and the upcoming 1.9 release will also alter the 
username field again, resulting in the scenario I described above. So 
unless 
we explicitly warn against this in the documentation, we should find a 
suitable solution for this. 

Marten

Op woensdag 9 september 2015 12:02:57 UTC+2 schreef Emmanuelle Delescolle:
>
> if we change the code in Django that does order resolution even slightly 
>> it could result in different operation orders or even different "final" 
>> rendered models.
>
>
> The order of migrations isn't something which is local to this feature, it 
> is something which isn't fixed (probably by design, correct me if I'm 
> wrong) and if it is not "the right way" to do it, maybe it should be part 
> of another issue.
>
> Once again, correct me if I'm wrong but the only way to have different 
> final rendered models would be the original third-party app 
> defining/altering a field which has already been defined/altered by your 
> app, resulting, in regards of the current proposal, in clashing fields.
> Creating a field which clashes with another app's field is something bad, 
> there are nine chances out of ten that fixed migration order will not solve 
> your overall problem: you created a field named the same as another field, 
> except if you have a psychic connection with the original library's author 
> you probably have a different usage for the field (however slight the 
> difference may be) and, if you really need to upgrade that third party 
> library, you have a whole other mess to fix than conflicting migrations so 
> I am really wondering if this is worth the hassle.
> If you create two models with the same meta db_table, django doesn't come 
> to your rescue and propose a solution, it is something you shouldn't have 
> done and now you have to deal with it. I think this "edge case" is in the 
> same area.
>
> would prefer some better- 
>> looking solution -- e.g. "project migrations" (there are other reasons to 
>> think of them, like, special migrations to change swappable models); but 
>> unless some such idea gets some backing, I'd be only -0 on this. 
>>
>
> A "project" is just a module, so if you create a "migrations" directory, 
> add an __init__.py inside it and add it to your INSTALLED_APPS, you can 
> start placing migrations inside it. That's actually where I put those 
> "migrations for other apps" at the moment.
> And BTW, changing a swappable model is another "legitimate" example of a 
> migration being created in a third party app (django.contrib.admin) while 
> strictly using "recommended" features of Django.
>
> Cheers
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discuss

Re: Ability to migrate other applications

[Emmanuelle Delescolle]

>
> if we change the code in Django that does order resolution even slightly 
> it could result in different operation orders or even different "final" 
> rendered models.


The order of migrations isn't something which is local to this feature, it 
is something which isn't fixed (probably by design, correct me if I'm 
wrong) and if it is not "the right way" to do it, maybe it should be part 
of another issue.

Once again, correct me if I'm wrong but the only way to have different 
final rendered models would be the original third-party app 
defining/altering a field which has already been defined/altered by your 
app, resulting, in regards of the current proposal, in clashing fields.
Creating a field which clashes with another app's field is something bad, 
there are nine chances out of ten that fixed migration order will not solve 
your overall problem: you created a field named the same as another field, 
except if you have a psychic connection with the original library's author 
you probably have a different usage for the field (however slight the 
difference may be) and, if you really need to upgrade that third party 
library, you have a whole other mess to fix than conflicting migrations so 
I am really wondering if this is worth the hassle.
If you create two models with the same meta db_table, django doesn't come 
to your rescue and propose a solution, it is something you shouldn't have 
done and now you have to deal with it. I think this "edge case" is in the 
same area.

would prefer some better- 
> looking solution -- e.g. "project migrations" (there are other reasons to 
> think of them, like, special migrations to change swappable models); but 
> unless some such idea gets some backing, I'd be only -0 on this. 
>

A "project" is just a module, so if you create a "migrations" directory, 
add an __init__.py inside it and add it to your INSTALLED_APPS, you can 
start placing migrations inside it. That's actually where I put those 
"migrations for other apps" at the moment.
And BTW, changing a swappable model is another "legitimate" example of a 
migration being created in a third party app (django.contrib.admin) while 
strictly using "recommended" features of Django.

Cheers

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fbea4a6f-e543-452e-8e38-fd1c41fdde86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL Dispatcher

[Marten Kenbeek]

Hi James,

Thanks for keeping this alive while I had some personal issues to sort out. 
I'll be working on this again, though I can use all the help I can get. 

As for the work that still needs to be done:

   - 3.1 is done, mostly as a proof-of-concept that can be found 
   at https://github.com/knbk/django/tree/url_dispatcher
   - 3.2 is done. I've worked on this in separate PR's, which have all been 
   merged by now. 
   - 3.3: 
  - Legacy functionality has been implemented, namely through the 
  RegexPattern, LocalizedRegexPattern and LocalePrefix constraints.
  - I've kept a lot of functional tests, and I believe the unit tests 
  have decent coverage. It would be good to have more tests, but I don't 
  think it's a necessity. 
  - Yes, pretty much all the documentation must still be written. 
  - These could be implemented pretty straight-forward in separate 
  patches after the main project has been merged. 
   
The resolver is not quite as fast as I'd hoped, especially `reverse()`. 
There are some trade-offs we can make, but we'll have to decide which are 
worth it. 
I think that is the main problem we need to tackle before we push for a 
merge. 

Marten

Op dinsdag 25 augustus 2015 20:57:14 UTC+2 schreef Tim Graham:
>
> Thanks for taking this on, James. I do think it would be best to defer 
> this to Django 1.10 rather than try to rush it into Django 1.9 at this 
> point. Also, there are several URL related deprecations scheduled to 
> complete in 1.10 which should simplify things (I've started on those 
> removals here: https://github.com/django/django/pull/5143). Absent 
> another interested person, I should be able to mentor you on this during 
> the Django 1.10 release cycle (which can start once we cut the stable/1.9.x 
> branch after 1.9 alpha around September 21). In the meantime, if you want 
> take a look for some simpler tickets to tackle to get a feel for our 
> contribution process, I think that would be helpful.
>
> On Tuesday, August 25, 2015 at 2:25:07 PM UTC-4, James Addison wrote:
>>
>> In the interests of keeping the excellent work done by Marten Kenbeek 
>> (knbk on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current 
>> and moving along, I've created a new branch [2] and rebased it against 
>> current master. (I am doing this because it seems like Marten is no longer 
>> able to continue working on the effort. *If this should change or is 
>> incorrect, Marten, please let me/us know!*)
>>
>> To try and find how far along the project is, I've quickly compared the 
>> original GSOC outline/timeline [1] against my updated branch [2] to see 
>> what is done/remaining:
>>
>>- section 3.1 (Design phase) I believe was done, but am unable to 
>>find anything other than a few posts on the django-developer mailing list 
>> - *is 
>>there a source for this?*
>>- section 3.2 (Namespace overhaul) hasn't been addressed that I can 
>>tell - *I'd recommend dropping this as it isn't core to the effort*
>>- Items completed in section 3.3 (Dispatcher API): 3.3.[1-4]
>>- *Items remaining* in section 3.3: (Dispatcher API): 3.3.[5-9] - 
>>some highlights:
>>   - re-implementing some legacy functionality for backward 
>>   compatibility (ie. RegexURLPattern)
>>   - additional tests
>>   - lots of documentation!
>>   - additional resolvers (ie. scheme, sub-domain, etc)
>>
>>
>>
>> Please keep in mind that I'm mostly unfamiliar with the internals of 
>> Django core elements, so I may have easily overlooked/mistook relevant 
>> information. I'd appreciate any other review/input as well. Here is the 
>> branch comparison [3] on Github.
>>
>> Based on the Django 1.9 release schedule, I have doubts that this will be 
>> merged in for feature freeze, which is unfortunate. I would like to think 
>> that I am up to the task, but the URL functionality in Django is about as 
>> 'core' as it gets and I would not want to bite off more than I can chew 
>> without backup. Any thoughts on the continued viability of this effort? Is 
>> this something that someone inexperienced with Django internals should take 
>> on? If so, I'd definitely need coaching!
>>
>> Lastly, I want to mention that I do have a new project in which I had 
>> been using Marten's branch (and am now using my own branch [2]), and it has 
>> been functionally solid for the scheme, (sub) domain and url resolving and 
>> reversing use cases. See the the urls.py [4] from that project to whet 
>> your appetites as to the possibilities of all this. :)
>>
>> Previous discussions on the django-developers mailing list [5].
>>
>> [1] 
>> https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904
>> [2] https://github.com/jaddison/django/tree/gsoc2015_url_dispatcher
>> [3] 
>> https://github.com/django/django/compare/master...jaddison:gsoc2015_url_dispatcher
>> [4] https://gist.github.com/jaddison/18dea1bf93767f326aa5
>> [

Re: Ability to migrate other applications

[Marten Kenbeek]

Say A.0002 and B.0001 are different leaf nodes for A.0001, and both alter 
the same field. 
Now, on a clean database, the order is pretty stable. If that order is 
A.0001, A.0002, B.0001,
you'll always end up with the field from B.0001. This is also what the 
autodetector sees. 

If you first create and apply the migrations A.0001 and B.0001, and then an 
update to A adds
the new migration A.0002, the database will end up with the field from 
A.0002. The autodetector 
will still see the field from B.0001, and won't  create a new migration, so 
if the final model has 
the field from B.0001, you have a mismatching database table. 

I think the fact that the order depends on which migrations have been 
applied is enough to require 
a merge migration. 

Marten

Op dinsdag 8 september 2015 21:33:10 UTC+2 schreef Andrew Godwin:
>
> I still feel like merge migrations are necessary, if not only because 
> they're a way of reducing the potential collision area of migration 
> ordering from different branches, but it might be that the solver is 
> predictable enough that it's not a problem. Two separate branches in 
> migrations still don't have an order relative to each other, so if we 
> change the code in Django that does order resolution even slightly it could 
> result in different operation orders or even different "final" rendered 
> models.
>
> Andrew
>
> On Mon, Sep 7, 2015 at 5:16 PM, Shai Berger  > wrote:
>
>> Ok, two things:
>>
>> 1) Markus' idea of having more than one folder for migration modules seems
>> reasonable enough. I disagree with his comment about the placement of 
>> merge
>> migrations --
>>
>> > Django needs to know where to
>> > place the merge-migration. I'd go with the first item in the list
>>
>> I'd require an explicit selection by the user; I'd still want to make 
>> sure the
>> selected path is one of those specified for migration modules, so a 
>> dialog for
>> selection may be more appropriate than a command-line parameter.
>>
>> BUT
>>
>> 2) Emma's experiment, essentially, proves that the migration system can 
>> live,
>> migrate, and generate new migrations with two leaf-migrations present. 
>> Which
>> begs the question -- are merge migrations really necessary at all? I know 
>> why
>> they were necessary for South, where migrations in an app were ordered
>> linearly, but we have grown past that.
>>
>> If, as I now suspect, we actually don't need them, then the whole idea 
>> sounds
>> much more reasonable. I still feel funny about a migration which belongs 
>> to
>> one app and works on the models of another, and would prefer some better-
>> looking solution -- e.g. "project migrations" (there are other reasons to
>> think of them, like, special migrations to change swappable models); but
>> unless some such idea gets some backing, I'd be only -0 on this.
>>
>> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f621c8bd-9c87-4c79-a99c-caa13365368f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making the test suite run faster

[Aymeric Augustin]

Le 8 sept. 2015 à 18:42, Michael Manfre  a écrit :
> 
> I agree with Shai. The database backend needs to be able to control this 
> feature.

Yes, I'm implementing that. The feature will be opt-in for database backends.

-- 
Aymeric.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/84B9E724-B7F2-4B2A-AD1A-B5E33160B818%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.