Right now, storage_path is a db_index. Pretty much every field on the AdjustedImage model is, and there's a unique index on all of the Area fields. This was done a long time ago on the theory that db indexes are a good thing - there's no proof that this actually makes queries faster. Since everything is pretty much an index, chances are it actually slows things down.
The one field that really makes sense as a db index (storage_path) is length-limited to 300 characters - but if someone's using MySQL, they'll get this error: Specified key was too long; max key length is 767 bytes. For now, we should just remove the key. Shortening the storage_path length could also work, but then it would chop off paths sooner. (Though arguably if you're using storage paths that long, you have other issues.) Still, since there's no proof that such a key really is beneficial, we should probably remove it.
Right now, storage_path is a db_index. Pretty much every field on the AdjustedImage model is, and there's a unique index on all of the Area fields. This was done a long time ago on the theory that db indexes are a good thing - there's no proof that this actually makes queries faster. Since everything is pretty much an index, chances are it actually slows things down.
The one field that really makes sense as a db index (storage_path) is length-limited to 300 characters - but if someone's using MySQL, they'll get this error: Specified key was too long; max key length is 767 bytes. For now, we should just remove the key. Shortening the storage_path length could also work, but then it would chop off paths sooner. (Though arguably if you're using storage paths that long, you have other issues.) Still, since there's no proof that such a key really is beneficial, we should probably remove it.