Here is another issue that I have analysed.
*When the autogenerated field name is too long, there is no proper
displaying of errors, many a time silent failures for some database.*
Written a fix, although some thinking is required in writing the tests.
@classmethod
def _check_long_column_name(cls):
errors = []
allowed_len = None
db_alias = None
for db in settings.DATABASES.keys():
# skip databases where the model won't be created
if not router.allow_migrate(db, cls):
continue
connection = connections[db]
allowed_len = connection.ops.max_name_length()
db_alias = db
if allowed_len is not None:
for f in cls._meta.local_fields:
_, column_name = f.get_attname_column()
"""
Check if auto-generated name for the field is too long
for the database.
"""
if f.db_column is None:
if len(column_name) > allowed_len:
errors.append(
checks.Error(
'Autogenerated column name too long for field
"%s".'
'Maximum length is "%s" for "%s".' %
(column_name, allowed_len, db_alias),
hint='Set the column name manually using
db_column',
obj=cls,
)
)
return errors
Also it is seen, that *model name truncation is not done properly.*
self.db_table = truncate_name(self.db_table,
connection.ops.max_name_length()) is done.
But, something like the following would be more correct:
db = router.db_for_read(self.model)
self.db_table = truncate_name(self.db_table,
connections[db].ops.max_name_length())
We could also use router.allow_migrate as above.
Also when *db_table name truncation is done, we get a weird message*:
#models.py
class
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(models.Model):
name = models.CharField(max_length=40)
python manage.py syncdb
Creating table
probs_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa36a3
Warning: Data truncated for column 'name' at row 13
Instead of reporting about the truncated name of the model table, it seems
to tell about the first field of that table.
This is something done by the backend I believe.*(Correct me if I am
wrong.)*
Assuming if above is correct, then what we can do is create a warning using
warning.warn(...) about the correct issue.
Then we can remove the false warning arising from the db.
A mention of similar problem at #18959 is there, but as far as I have
understood it worksforme or else if someone can help me reproduce the
problem/error if I am wrong, then it would be very helpful.
Regards,
Anubhav Joshi
IIT Patna
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
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/588db101-7dd8-49dd-9f55-8dfdd0e98873%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.