Re: [ANNOUNCE] Django security releases issued (1.4.21, 1.7.9, and 1.8.3)

[tomv]

Out of interest what's wrong with casting to int and checking for 
exceptions?

This is the removed code:

try:
int(value)
except (ValueError, TypeError):
raise ValidationError(_('Enter a valid integer.'), code='invalid')

Does this match different strings than the new regex: re.compile('^-?\d+\Z') 
? Or is it more about performance, OverflowError etc?

-- 
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/fa196dc9-c002-4f4b-9bb3-a0ab64d6ff2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

[tomv]

Thanks for clarifying that Mark. I've updated the ticket mentioning that 
we'll leave the resolution of the index name collision issue to your DEP.

On Monday, 1 December 2014 22:35:49 UTC, Marc Tamlyn wrote:
>
> I intend the new indexes to have customisable names, and to deconstruct 
> their name into the migration. This means that any changes in the name (if 
> the name is autogenerated) would be detected. It should be possible to do 
> renames.
>
> It is worth noting that mysql (and sqlite obviously) do not support 
> renaming of indexes and the index would need to be dropped and rebuilt. On 
> large tables this would be a problem, so we'll need some warnings in the 
> documentation about how to fix the index name so it is not identified as a 
> change.
>

-- 
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/ab045baf-d57a-42cf-9b76-8596cb34d349%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

[tomv]

Thanks for pointing out the index improvement DEP Shai, I hadn't seen that 
yet.

It's important to note that right now, index names are not re-creatable in 
retrospect. They rely on the names of models and fields, that are free to 
be renamed. So a complete rethink will be needed if introspection can no 
longer be used for user-specified types of indexes. For example, maybe the 
user should choose the name, which they should make unique at the app 
level? Or if not, Django will need to either keep a record of the generated 
index name somewhere, or start renaming indexes to keep them up-to-date 
with the components in their names.

What's the best way to proceed with the index name collision ticket #23577 
 at this point then? I can:

   1. re-write my "use migration names in index names" branch 
   

 
   to allow index suffix names passed from migration operations?
   2. or declare there's no consensus on the solution / we'll wait for 
   Mark's index DEP - in which case, can I submit my tests 
    as 
   xfails?

Cheers,
Tom

On Thursday, 27 November 2014 20:44:28 UTC, Shai Berger wrote:

> Hi, 
>
> Just noted this thread, and I have two points: 
>
> 1) Using the migration name in the index isn't really "predictable", and 
> isn't 
> even completely stable (the name changes when migrations are squashed), 
> unless 
> I'm missing something. 
>
> 2) The current practice of identifying indexes by the columns they use is 
> sufficient now, but may not suffice when we have finer control over 
> indexes (Marc 
> Tamlyn is writing the DEP[1] for this). I can very easily see, for 
> example, 
> uses for two partial indexes on the same field (on PG, where partial 
> indexes 
> exist). 
>
> I'm not sure we need fully predictable index names now, but my hunch is 
> that 
> we are going to need them down the road, and an explicitly-set suffix is a 
> lot 
> closer to what we'll need than a random one. 
>
> My 2 cents, 
> Shai. 
>
>
> [1] https://github.com/django/deps/pull/6/files 
>

-- 
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/c1e8088e-37d3-45d9-9cda-1b8f965d9124%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

[tomv]

So one option as you suggest Carl, is to pass a hard coded string into the 
Operation when it's instantiated in the user's migration file. I've taken a 
similar approach, starting one level lower, injecting the migration name 
into database_forwards methods. 
https://github.com/tomviner/django/compare/ticket_23577_with_poc_migration_name_fix

This then passing into schema_editor public method calls (create_model, 
add_field and alter_field, which all need their signatures changed over 
BaseDatabaseSchemaEditor and all the database specific schema editor 
backends). Then the migration name is passed through internal schema editor 
methods like _alter_field, _create_unique_sql, _create_index_sql, 
_create_fk_sql and finally on to _create_index_name.

See how the tests have to pass in extra_index_suffix='schema_test.000x' as 
they don't go through an actual migration file.

To sum up this solution: it's not localised and it's not pretty. I'm sure 
it could be tidied up a little, but unless it can be collapsed to a much 
smaller patch, I'd say having deterministic index names isn't worth the 
impact.


Instead, I propose the following solution: a random string injected into 
the formation of all index names. A much more localised patch: 
https://github.com/tomviner/django/compare/ticket_23577_with_poc_random_string_fix

So final call for examples where having predictable index names matter!

One thing I'm still looking at, regardless of the solution chosen, is 
whether we need to include spatial indexes too.

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/96b5254c-ce27-481e-9087-d655cedf3a02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

[tomv]

Hi all,

At the Django under the hood sprint I picked up #23577 
 which says, in the general 
case: 

   1. For any database object when django creates an associated index
   2. If you rename that object
   3. Then re-create another with the original's name
   4. You get a collision in the name of the associated index

This applies in the simplest case to renaming any field with db_index=True, 
then re-creating another in it's place. But also renaming a model 
containing a ForeignKey or indexed field, then re-creating the model. (All 
via db migrations)

The instinctive desire is to rename indexes when renaming objects whose 
name was used in the index creation. But speaking to Andrew Godwin, he 
feels this would be quite a large challenge, across all our supported 
backends.

The alternative he suggested was to add a random element to all index names 
the schema editor creates. This post is seeking to validate that proposal.

Note: it's only the names of indexes at issue here, databases keep 
everything pointing at the right objects. There's also no issue with Django 
needing to access an index via a predictable name, as there's introspection 
which grabs indexes according to the objects they work on.

Bonus question: given the scenario above, can we come up with a source of 
index naming that differs after the "parent" object is renamed/re-created, 
but which remains deterministic? Something like pulling in a hash of the 
whole app model state. Unfortunately, as we aim to output migrations to 
sql, we can't have any introspection at migration application time, so for 
example no checking for name collisions.

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/99246d04-b205-42a6-a389-a0370bea3cd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Explicit relative imports

[tomv]

Tom, there's another way to remove confusion/decision making about import 
ordering: https://pypi.python.org/pypi/isort 

For Django it could be mentioned on the contrib docs and `isort 
--check-only` run with flake8.

On Thursday, 13 November 2014 14:57:15 UTC+1, Tom Christie wrote:
>
> Contrary voice here, but I don't dig explicit relative imports, it's just 
> adds an extra decision point for no real benefit.
>
> Personally I always recommend full absolute imports, ordered strictly 
> alphabetically - there's then never any room for confusion or decision 
> making around how the imports should be written, and it's always tidy and 
> consistent.
>
> Not looking to necessarily change the Django project's stance on that, but 
> that's the style I use throughout my projects and it's trivial to stick to. 
>
> Cheers,
>
>   Tom
>
> On Wednesday, 12 November 2014 21:59:42 UTC, Jannis Leidel wrote:
>>
>>
>> > On 11 Nov 2014, at 22:51, Aymeric Augustin <
>> aymeric@polytechnique.org> wrote: 
>> > 
>> > Hello, 
>> > 
>> > We’ve started using explicit relative imports in newer parts of the 
>> Django source tree. They’re short and readable. That’s good. 
>> > 
>> > I would like to add guidelines about imports in the coding style guide 
>> in order to improve consistency. 
>> > 
>> > My inclination would be to recommend relative imports within 
>> “components” but avoid them between “components”, where a component is: 
>> > 
>> > - a well-defined sub-framework (django.core.cache, django.db, 
>> django.forms, django.template, etc.) 
>> > - a contrib app 
>> > - an app in the tests/ directory 
>> > - etc. 
>> > 
>> > I would discourage going back into parent modules with relative imports 
>> because statements such as `from ...spam import eggs` are hard to parse. 
>> > 
>> > You can see an example of this style in django.apps which has only 
>> three files. 
>> > 
>> > What do you think? 
>>
>> Yup, the way to go. 
>>
>> Jannis
>
>

-- 
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/1eee3f88-886c-4101-87b9-3fcc5f83f9a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Better error message for django.core.urlresolvers.reverse

[tomv]

Hi Gregor,

Cool, will do this after my holiday.

Tom

On Jun 12, 12:01 pm, Gregor Müllegger <gre...@muellegger.de> wrote:
> Hi Tom,
>
> currently it seems that the url resolver that is actually raising the
> error doesn't know about in which namespace he acts. However I think
> as well that this might be a usefull addition to the error message.
>
> I would suggest adding a ticket to django's bugtracker [1] for this.
> Ideally write a patch for this issue and attach it to the ticket.
>
> [1]https://code.djangoproject.com/
>
> --
> Servus,
> Gregor Müllegger
>
> 2011/6/9 tomv <webfact...@tomviner.co.uk>:
>
>
>
>
>
>
>
> > Hi,
>
> > This is the current error message when a url name or argument doesn't
> > exist:
>
> >>>> reverse('core:non_existant')
> > NoReverseMatch: Reverse for 'non_existant' with arguments '()' and
> > keyword arguments '{}' not found.
>
> > Is there support for adding the namespace into the error message?
>
> > Tom
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Better error message for django.core.urlresolvers.reverse

[tomv]

Hi,

This is the current error message when a url name or argument doesn't
exist:

>>> reverse('core:non_existant')
NoReverseMatch: Reverse for 'non_existant' with arguments '()' and
keyword arguments '{}' not found.

Is there support for adding the namespace into the error message?

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.