Migrating to initial migration: "ORA-00955: name is already used by an existing object"

[Carsten Fuchs]

Dear Django developers,

in a Django project that was created pre-1.7, did not use South before,
and was recently upgraded to Django 1.7 and is otherwise fine, I'm now
trying to convert it to use migrations, following the docs at
<https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps>.

It seems that creating the initial migrations with `makemigrations`
works well, but the first run of `migrate` aborts with error
"django.db.utils.DatabaseError: ORA-00955: name is already used by an
existing object". Please see the full output below.

Unfortunately, I don't know enough about migrations to be able to debug
this myself, or to understand what the problem is.

What are good next steps, or where should I look for the cause of this
problem?

Best regards,
Carsten



(Zeiterfassung)carsten@blue-ring-ubuntu:~/Zeiterfassung$ rm -rf
Lori/migrations/

(Zeiterfassung)carsten@blue-ring-ubuntu:~/Zeiterfassung$ ./manage.py
makemigrations Lori
Migrations for 'Lori':
0001_initial.py:
- Create model AUB
- Create model Ausbezahlt
- Create model Aushilfslohn
- Create model Bereich
- Create model Code
- Create model Erfasst
- Create model KalenderEintrag
- Create model Kostenstelle
- Create model Mitarbeiter
- Create model MonatsSalden
- Create model Oeffnungszeiten
- Create model PekoBenchmarkCache
- Create model PekoGewichte
- Create model Region
- Create model Schicht
- Create model Status
- Create model SystemEmailEmpfaenger
- Create model TempMaBereichZuordnung
- Create model Termin
- Create model Umsatzgruppe
- Create model UserProfile
- Create model Vertragsverlauf
- Create model Vorblendplan
- Create model Vortraege
- Alter unique_together for schicht (1 constraint(s))
- Add field region to pekogewichte
- Add field fil_gruppe to pekobenchmarkcache
- Alter unique_together for pekobenchmarkcache (1 constraint(s))
- Alter unique_together for monatssalden (1 constraint(s))
- Add field tmp_bereiche to mitarbeiter
- Add field vbp_neu to mitarbeiter
- Add field fil_gruppe to kostenstelle
- Add field parent to kostenstelle
- Add field region to kostenstelle
- Add field kstellen to kalendereintrag
- Add field regionen to kalendereintrag
- Add field key to erfasst
- Add field last_user to erfasst
- Add field status to erfasst
- Alter unique_together for erfasst (1 constraint(s))
- Add field region to bereich
- Add field key to ausbezahlt
- Alter unique_together for ausbezahlt (1 constraint(s))
- Add field ma to aub

(Zeiterfassung)carsten@blue-ring-ubuntu:~/Zeiterfassung$ ./manage.py migrate
Operations to perform:
Apply all migrations: admin, contenttypes, Lori, auth, sessions
Running migrations:
Applying Lori.0001_initial...Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 385, in execute_from_command_line
utility.execute()
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/base.py",
line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/base.py",
line 338, in execute
output = self.handle(*args, **options)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
line 161, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/migrations/executor.py",
line 68, in migrate
self.apply_migration(migration, fake=fake)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/migrations/executor.py",
line 102, in apply_migration
migration.apply(project_state, schema_editor)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/migrations/migration.py",
line 108, in apply
operation.database_forwards(self.app_label, schema_editor,
project_state, new_state)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/migrations/operations/models.py",
line 36, in database_forwards
schema_editor.create_model(model)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/backends/schema.py",
line 261, in create_model
self.execute(sql, params)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/backends/schema.py",
line 102, in execute
cursor.execute(sql, params)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/backends/utils.py",
line 81, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/backends/utils.py",
line 65, in execute
return self.cursor.execute(sql, params)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/utils.py",
line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/backends/utils.py",
line 65, in execute
return self.cursor.execute(sql, params)
File
"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/db/backends/oracle/base.py",
line 916, in execute
return self.cursor.execute(query, self._param_generator(params))
django.db.utils.DatabaseError: ORA-00955: name is already used by an
existing object

[Markus Holtermann]

Hey Carsten,

Did you see the chapter at the end of the page you linked to: Upgrading from South: https://docs.djangoproject.com/en/1.7/topics/migrations/#upgrading-from-south

1. Make sure the database schema defined by your models (and Django migrations) exactly matches the one in the database (this includes null constraints, indexes, etc.) to prevent errors in the future

2. Run "manage.py migrate --fake"

/Markus

[Carsten Fuchs]

Hi Markus,

thanks for your reply!

Am 02.02.2015 um 22:59 schrieb Markus Holtermann:
> Did you see the chapter at the end of the page you linked to: Upgrading from South: https://docs.djangoproject.com/en/1.7/topics/migrations/#upgrading-from-south

Well, yes, but I'm *not* upgrading from South, the project did not use
any migrations at all before.

However, in its very beginnings, it started with a legacy database that
was used with a PHP application that many years ago was replaced with
this Django project.

> 1. Make sure the database schema defined by your models (and Django migrations) exactly matches the one in the database (this includes null constraints, indexes, etc.) to prevent errors in the future

If this is the problem, I'm not sure how to figure out what the
differences actually are, or what mismatch it is that brings the
`migrate` command to abort. Can I somehow have Django provide more
details on the matter?

Best regards,
Carsten

[Carsten Fuchs]

Hi all,

Am 02.02.2015 um 22:50 schrieb Carsten Fuchs:
> It seems that creating the initial migrations with `makemigrations`
> works well, but the first run of `migrate` aborts with error
> "django.db.utils.DatabaseError: ORA-00955: name is already used by an
> existing object". Please see the full output below.

A quick update:

Running `migrate` with very verbose output (`-v 3`) does not provide any
relevant extra information, just:

> [...]

> Running migrations:
> Applying Lori.0001_initial...Traceback (most recent call last):

> [... same as before]


Also, I re-tried with `managed = False` added to each model's Meta
class, but to no avail: the error is exactly the same as reported in my
previous post. (With `managed = False`, `makemigrations` lists all the
models, but not the previously indicated constraints or the fields. The
exception with `migrate` about ORA-00955 remains the same, though.)


Any help or hints would very much be appreciated!

Many thanks and best regards,
Carsten

[Carsten Fuchs]

Hi all,

another update:

My developer system's local Oracle database content was created from
importing a dump of a production database. On Monday night I'll have a
chance to safely try to create and apply the initial migrations on the
production database, rather than my dev system. Maybe some subtle issues
from the export-import cycle are responsible for the ORA-00955 on my
developer machine, and so I'll just give it a try.

Also, I suspect that if not for the ORA-00955 error, the initial
migrations for this app would turn out to be "FAKE" applied -- just as
was the case with other previously unmigrated apps that I successfully
added initial migrations to after the upgrade to Django 1.7.

However, I don't quite dare yet running

./manage.py migrate --fake

explicitly, mostly because I'm not sure how to undo or recover if there
are subsequent problems, or if there is a way to re-try, etc.

(On the other hand, if this worked and there were errors only much
later, they would probably occur after individual, small changes, thus
much smaller migration files, and thus (I recon) much easier to pin down
as from the big stack trace about the ORA-00955...)

Any help or hint would still be very much appreciated.

Best regards,
Carsten

[Carsten Fuchs]

Hi all,

it seems like I found the culprit, along with a simple solution:
https://code.djangoproject.com/ticket/24407

:-)

Best regards,
Carsten