That's a huge help in understanding the underlying concepts. Thank you very much. While attempting to answer my question, you actually led me to the answer myself.
I was trying to generate an index with South and that was raising the error. Essentially, I was trying to apply an index to a foreign key field, without knowing that ForeignKey fields are indexed by default, even in 1.0. I was creating an index on a field that was already indexed and thought I had a naming conflict. Sorry for wasting your time. I'm a little new to Django, having spent a lot of years with SQLAlchemy, and now, coming into a large, existing, Django project. So, I'm still learning the intricacies. Thanks so much for taking the time to respond. You're a rock star. -Josh On Sep 2, 4:54 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Fri, Sep 3, 2010 at 6:03 AM, HiTekElvis <hitekel...@gmail.com> wrote: > > Have a db that was generated under 1.0. Hence, foreign keys in MySQL > > have been named [tablename]_[fieldname]_id. > > A slight correction - foreign key *indexes* will be named like that; > the fields themselves don't include the table name. > > > However, when upgrading to 1.2, I tried to create an index on that > > field and got an error, because 1.2 names its foreign keys > > [tablename]_[hash] and its index keys [tablename]_[fieldname]_id. > > > Is there a solution for this? A script that renames the foreignkeys > > to follow the 1.2 format, or a way to alternatively name the index > > key? > > > Apologize if this is already documented somewhere. I looked all over > > and didn't find anything. > > There isn't a simple script, because what you're describing > *shouldn't* be posing a problem. > > Django doesn't touch tables once they're originally created. > Therefore, once a table has been created, there's no way to get Django > to create a new index (or make any other table modification for that > matter). > > You *could* use sqlall or sqlindexes commands et al to work out the > likely syntax for any new table modifications; however, if you're > taking snippets of those commands and running them manually over your > database (e.g., in your case, taking some index creation commands) > then you'll need to audit them to make sure they are appropriate to > your existing database. There's a reason Django provides sqlindexes, > but doesn't provide a way to apply that SQL directly to your database > -- we want to make sure that you audit any SQL that we generate but > don't provide a way to automatically apply. > > The change you're referring to was introduced to avoid warnings and > errors that you must be either seeing or suppressing. It relates to > the use of column names that exceed system limits -- on MySQL, that's > 64 characters. If a column name, table name or index name exceeds this > limit, MySQL ignores the 65+ characters, potentially introducing an > ambiguity in queries. To compensate, all indexes are named using the > scheme table_name_HASH, with the hash constructed from a digest of the > fields involved. > > However, the *name* of the index doesn't actually matter. If you > didn't have an index in an older version of some code, and now you do, > it doesn't matter what you call the new index -- the name is just an > identifier. Once it's created, Django doesn't have anything to do with > it; it exists, and MySQL handles all the interaction with the index. > > So -- I'm a little confused as to the errors you are seeing. Can you > elaborate? > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
