list/set inconsistency breaks syncdb

[arthur@…]

Found on SVN as of rev 15400.

$ python manage.py syncdb
Creating tables ...
Traceback (most recent call last):
  File "manage.py", line 11, in <module>
    execute_manager(settings)
  File "django/core/management/__init__.py", line 438, in execute_manager
    utility.execute()
  File "django/core/management/__init__.py", line 379, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "django/core/management/base.py", line 191, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "django/core/management/base.py", line 220, in execute
    output = self.handle(*args, **options)
  File "django/core/management/base.py", line 351, in handle
    return self.handle_noargs(**options)
  File "django/core/management/commands/syncdb.py", line 102, in handle_noargs
    tables.append(connection.introspection.table_name_converter(model._meta.db_table))
AttributeError: 'set' object has no attribute 'append'

tables is expected to be a list here but is created at django/trunk/django/db/backends/__init__.py BaseDatabaseIntrospection.django_tables_name as a set (but a list instead if only_existing is True..).
A simple tables = list(table) at the appropriate line in django_tables_names has fixed syncdb for me.

[Obey Arthur Liu <arthur@…>]

patch

[Russell Keith-Magee]

The regressiontests/introspection tests contains tests for django_table_names(); tests for this case should be added.

[Ramiro Morales]

Actually, the tables variable is obtained from a a call to the backend DatabaseIntrospection table_names() method and not from a call to django_table_names() so I don't see how a value returned by the latter would end being used at that point.

I agree with the proposal that the django_table_names() return value inconsistency should be fixed, though.

[Ramiro Morales]

In [17510]:

Fixed #15216 -- Made return type of an internal DB introspection method consistent.

Thanks arthur AT milliways DOT fr for the report and patch.