Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2016-06-29 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"16614dcd5cad50648ef75021b919fc90dd449312" 16614dc]:
 {{{
 #!CommitTicketReference repository=""
 revision="16614dcd5cad50648ef75021b919fc90dd449312"
 Fixed #25694 -- Removed incorrect _uniq suffix on index names during
 migrations.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.01f338af529b1b96e4ea9b548dd743e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2016-06-29 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by jdufresne):

 * needs_better_patch:  1 => 0


Comment:

 > Good. That makes the proposal redundant.

 Ok thanks. Then I will proceed.

 I have updated the test to work with Oracle.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d5b85de2d2e3efebdb6bda9cfdd021d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2016-06-26 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by jdufresne):

 > So, you're saying Django already dropps all indexes on a field. Good.
 That makes the proposal redundant.

 Yes, it drops all indexes when there is a change in field's `db_index`
 state. A link to the code:

 
https://github.com/django/django/blob/ca77b509059831b055a3b735ff77e042f8e1c0eb/django/db/backends/base/schema.py#L537-L544

 Notice it loops over all indexes, instead of looking them up by name. The
 comment "no strict check, as multiple indexes are possible" even suggests
 this is intentional.

 However, if there is no change to the field's state, the indexes will not
 be dropped/recreated. So upgrading to the next Django version will leave
 some of the old names with `_uniq` around until the field's state changes.
 This is why I proposed the "version" idea. That could be recognized as a
 change in state.

 With this new understanding, is no action acceptable? Can I unset "Patch
 needs improvement"? Or should I got ahead with the "version" proposal?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.fd57cd36edbc03c3cc2a26c656567b1b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2016-06-26 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by MarkusH):

 Replying to [comment:5 jdufresne]:
 > > How do you suggest to take care of existing indexes that would now
 need to be renamed?
 >
 > Is this a required component of this bug fix?

 Yes. If we suddenly end up with either 2 indexes on a field applications
 become slow. And, if not handled correctly, when we have 2 indexes on a
 field and only drop 1 we might not be able to drop the field given a stale
 index.

 > With the current implementation, migrations don't actually care about
 the name of the index. It is just for human aesthetics. When removing an
 index, Django will remove all non-unique indexes regardless of the name. I
 actually bumped into this while working on another ticket and thought it
 would be a quick fix.

 So, you're saying Django already dropps all indexes on a field. Good. That
 makes the proposal redundant.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ebeda2b6759085bdf70afe3e3973bff8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2016-06-26 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by jdufresne):

 > How do you suggest to take care of existing indexes that would now need
 to be renamed?

 Is this a required component of this bug fix?

 With the current implementation, migrations don't actually care about the
 name of the index. It is just for human aesthetics. When removing an
 index, Django will remove all non-unique indexes regardless of the name. I
 actually bumped into this while working on another ticket and thought it
 would be a quick fix.

 If this is required, maybe there could be something like
 `Field.index_name_version` that could be inspected during migrations. If
 the version has changed, drop and recreate indexes. Then in the upgrade
 docs, recommend people run `makemigrations` after updating. Thoughts on
 this approach?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c7ffea6a70763c36a4f0e342031ebaea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2016-06-25 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by MarkusH):

 * needs_better_patch:  0 => 1


Comment:

 How do you suggest to take care of existing indexes that would now need to
 be renamed?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.fa75a1f381276e195133f871903347be%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2016-06-24 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by jdufresne):

 * cc: jon.dufresne@… (added)
 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/6834

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.e261e517c3e20c3d0af0327ae97c38f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2015-12-25 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by varunnaganathan):

 I came across 2 points:
 1.The error occurs on all databases except an sqlite3 one.
 2.If db_index=True in the first initial migration, _uniq is not
 suffixed.Whenever it is later being added in another migration _uniq is
 appended.
 Now,database indexes have to be unique in the table.Maybe since we are
 later altering the field , the _uniq has to be appended?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.41808ae6ea14a6f1e1ce3c7d730309e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name

2015-11-07 Thread Django
#25694: Migrate command creates a default index for a CharField with a wrong
'_uniq' suffix in the name
+
 Reporter:  synasius|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by charettes):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2cf193d15b9f482471e6e98c7bd96a09%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.