Ticket #293 (closed defect: invalid)

Opened 5 years ago

Last modified 4 years ago

Truncation problem with adding ManyToMany Fields results in "relation already exists"

Reported by: anonymous Owned by: andrew
Priority: major Milestone: 0.7.1
Component: migrations Version: 0.6.2
Keywords: truncation Cc:

Description

Using Postgres.

When you add a many to many that has long-named tables/fields, you can spill over the length limit and have collisions where South's truncation results in identically-named elements.

Error printed is "psycopg2.ProgrammingError?: relation "model_fields_etc_name_so_long_its_truncated" already exists"

A small test case is attached.

Attachments

longnameproject.zip (12.6 KB) - added by adamfast@… 5 years ago.
Django project / app that demonstrates the error.

Change History

Changed 5 years ago by adamfast@…

Django project / app that demonstrates the error.

comment:1 Changed 5 years ago by adamfast@…

Forgot to mention in the body above that the test project works fine with south left out of installed apps, using Django's normal syncdb mechanism.

comment:2 Changed 5 years ago by andrew

  • Status changed from new to assigned
  • Milestone set to 0.7

comment:3 Changed 5 years ago by andrew

  • Status changed from assigned to infoneeded

The index names are actually generated by Django; I've posted about this to the Django developers mailing list, since it's technically a bug in the core (it doesn't happen in this case since Django doesn't do indexes the same way, but I've recreated it with a different model).

It might well turn out to be a WONTFIX, since it's easy enough to pick shorter table and column names with Meta.db_table and Field.db_column, but we'll see.

comment:4 Changed 5 years ago by andrew

  • Milestone changed from 0.7 to 0.7.1

Bumping version.

comment:5 Changed 4 years ago by aball@…

I'm seeing this too. I'd be willing to help fix it if necessary, but I'd like a little bit more information to go on first. I really do not want to rename my tables.

Andrew, could you point me to your post to the Django developers? I'd also appreciate any additional information about how South index generation differs from what Django would normally do.

comment:7 Changed 4 years ago by andrew

Yes, that's the one. I'm not sure there'll be much decision on this till after 1.2 is released; for now, I recommend working around it by using shorter table names (you _could_ compile postgres, but I don't recommend it).

comment:8 follow-up: ↓ 10 Changed 4 years ago by aball@…

The index names should be made shorter automatically in Django 1.2, due to patches on ticket #13434 and #13441 which have made it to the trunk. Django 1.2 is now has a release candidate, but hasn't yet been released.

comment:9 Changed 4 years ago by andrew

  • Status changed from infoneeded to closed
  • Resolution set to invalid

Excellent, then in this case I'll close the ticket as invalid (since it wasn't solved by us).

comment:10 in reply to: ↑ 8 Changed 4 years ago by aball@…

Replying to aball@…:

The index names should be made shorter automatically in Django 1.2, due to patches on ticket #13434 and #13441 which have made it to the trunk. Django 1.2 is now has a release candidate, but hasn't yet been released.

For what it's worth, patching Django 1.1.1 with the patches attached to those tickets works fine.

Note: See TracTickets for help on using tickets.