Cache Invalidation table does not auto_increment [mysql]

Issue #420 wontfix
Ton Plomp created an issue

I'm running rhodecode on MySQL and the upgrade to 1.3.3 to 1.3.4 caused Rhodecode to crash on the first visit. I debugged it and changed the field definition of cache_invalidation.cache_id to auto_increment.

Here's the error tracebackin the rhodecode.log:

2012-03-31 16:52:43.465 ERROR [rhodecode.model.db] Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/RhodeCode-1.3.4-py2.7.egg/rhodecode/model/db.py", line 1120, in _get_or_create_key Session.commit() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/scoping.py", line 114, in do return getattr(self.registry(), name)(args, *kwargs) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 655, in commit self.transaction.commit() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 313, in commit self._prepare_impl() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 297, in _prepare_impl self.session.flush() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 1587, in flush self._flush(objects) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 1662, in _flush flush_context.finalize_flush_changes() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/unitofwork.py", line 347, in finalize_flush_changes self.session._register_newly_persistent(state) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 1207, in _register_newly_persistent "a load() event." % mapperutil.state_str(state) FlushError: Instance <CacheInvalidation at 0xb59ee4c> has a NULL identity key. If this is an auto-generated value, check that the database table allows generation of new primary key values, and that the mapped Column object is configured to expect these generated values. Ensure also that this flush() is not occurring at an inappropriate time, such as within a load() event.

2012-03-31 16:52:43.510 ERROR [rhodecode.model.db] Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/RhodeCode-1.3.4-py2.7.egg/rhodecode/model/db.py", line 1120, in _get_or_create_key Session.commit() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/scoping.py", line 114, in do return getattr(self.registry(), name)(args, *kwargs) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 655, in commit self.transaction.commit() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 313, in commit self._prepare_impl() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 297, in _prepare_impl self.session.flush() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 1587, in flush self._flush(objects) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/session.py", line 1658, in _flush flush_context.execute() File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/unitofwork.py", line 331, in execute rec.execute(self) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/unitofwork.py", line 475, in execute uow File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/persistence.py", line 64, in save_obj table, insert) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/orm/persistence.py", line 558, in _emit_insert_statements execute(statement, params) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 1450, in execute params) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 1583, in _execute_clauseelement compiled_sql, distilled_params File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 1697, in _execute_context context) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/engine/base.py", line 1690, in _execute_context context) File "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.6-py2.7-linux-i686.egg/sqlalchemy/engine/default.py", line 335, in do_execute cursor.execute(statement, parameters) File "/usr/lib/pymodules/python2.7/MySQLdb/cursors.py", line 174, in execute self.errorhandler(self, exc, value) File "/usr/lib/pymodules/python2.7/MySQLdb/connections.py", line 36, in defaulterrorhandler raise errorclass, errorvalue IntegrityError: (IntegrityError) (1062, "Duplicate entry '0' for key 'PRIMARY'") 'INSERT INTO cache

Comments (2)

  1. Marcin Kuzminski repo owner

    Very odd.

    This is how table definition looks for my mysql server for version 1.3.4:

    delimiter $$

    CREATE TABLE `cache_invalidation` (
      `cache_id` int(11) NOT NULL AUTO_INCREMENT,
      `cache_key` varchar(255) DEFAULT NULL,
      `cache_args` varchar(255) DEFAULT NULL,
      `cache_active` tinyint(1) DEFAULT NULL,
      PRIMARY KEY (`cache_id`),
      UNIQUE KEY `cache_id` (`cache_id`),
      UNIQUE KEY `cache_key` (`cache_key`)
    ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8$$
    

    I really don't know why it happened for you that you didn't get proper db created...

    Resolving as won't fix due to i cannot really fix that.

  2. Ton Plomp reporter

    That's OK, I noticed in another installation that the settings were correct, the invalid settings were in a DB that ran 1.2.0 beta previously. The strange thing is that 1.3.3 ran OK, while 1.3.4 crashed.

  3. Log in to comment