upgrading 0.4.x to 0.5 database error.

[Ed Wong]

Mads Kiilerich wrote:
> On 12/23/19 4:46 PM, Ed Wong wrote:
>> Hi,
>>
>> I'm running Kallithea 0.4.0 and tried to upgrade to 0.5.0; but at the
>> point of running "alembic -c my_new.ini upgrade", I got the following
>> error:
>>
> 
>> 2019-12-23 15:42:42.575 INFO  [alembic.runtime.migration] Running
>> upgrade 151b4a4e8c48 -> 4851d15bc437, db: migration step after
>> 95c01895c006 failed to add usk_public_key_idx in alembic step
>> b74907136bc1
> 
>> sqlalchemy.exc.OperationalError: (_mysql_exceptions.OperationalError)
>> (1170, "BLOB/TEXT column 'public_key' used in key specification without
>> a key length") [SQL: u'CREATE INDEX usk_public_key_idx ON user_ssh_keys
>> (public_key)'] (Background on this error at: http://sqlalche.me/e/e3q8)
> 
> 
> Hmm.
> 
> 
> One solution could perhaps be to change db.py to something like
> 
> _public_key = Column('public_key', Unicode(512), nullable=False)
> 
> ... but I'm not sure if 512 (or anything else) is reasonable - that
> depends on how long public keys ever can be, and what the lowest key
> constraints among databases is these days.
> 
> 
> But it seems like we only use the public_key index for deleting ssh keys.
> 
> Most likely, it will work just fine without that index. As a quick
> temporary workaround, I suggest skipping that upgrade step: edit
> kallithea/alembic/versions/4851d15bc437_db_migration_step_after_95c01895c006_.py
> and disable the checkings.

I commented out the three lines:


> def upgrade():
    pass
    # meta = sa.MetaData()
    # meta.reflect(bind=op.get_bind())

    # if not any(i.name == 'usk_public_key_idx' for i in
meta.tables['user_ssh_keys'].indexes):
    #     with op.batch_alter_table('user_ssh_keys', schema=None) as
batch_op:
    #         batch_op.create_index('usk_public_key_idx',
['public_key'], unique=False)


And now running "alembic -c my.ini upgrade head", I get:

(kalivenv) [root at vcsSeaBuildNet srv]# alembic -c my.ini upgrade head
2019-12-24 00:53:02.660 INFO  [alembic.runtime.migration] Context impl
MySQLImpl.
2019-12-24 00:53:02.660 INFO  [alembic.runtime.migration] Will assume
non-transactional DDL.
2019-12-24 00:53:02.669 INFO  [alembic.runtime.migration] Running
upgrade a020f7044fd6 -> ad357ccd9521, Drop locking
2019-12-24 00:53:04.849 INFO  [alembic.runtime.migration] Running
upgrade ad357ccd9521 -> b74907136bc1, Create table for ssh keys
2019-12-24 00:53:05.552 INFO  [alembic.runtime.migration] Running
upgrade b74907136bc1 -> 151b4a4e8c48, db: migration step after
93834966ae01 dropped non-nullable inherit_default_permissions
2019-12-24 00:53:06.717 INFO  [alembic.runtime.migration] Running
upgrade 151b4a4e8c48 -> 4851d15bc437, db: migration step after
95c01895c006 failed to add usk_public_key_idx in alembic step b74907136bc1


But it doesn't seem to affect much as I can still run Kallithea
and the ssh does seem to work and not to tempt fate with
deleting keys...

Thanks Mads!

Edmund



> It now seems like the right solution would be to change the code to use
> the fingerprint when deleting keys. I will work on that.
> 
> 
> /Mads
>