ipsilon

#234 ipsilon-upgrade-database fails with mysql/mariadb backend
Closed: Fixed by t0xic0der. Opened by arrfab.

Closed: Fixed
Reopen Issue

when configuring mysql:// uri for ipsilon, the initial tables aren't created by ipsilon-upgrade-database
The following changes in data.py made it possible to use mysql/mariadb backend :

--- data.py 2015-09-30 12:25:12.000000000 +0000
+++ data.py.working 2016-08-17 14:37:34.963120315 +0000
@@ -4,7 +4,7 @@
import datetime
from ipsilon.util.log import Log
from sqlalchemy import create_engine
-from sqlalchemy import MetaData, Table, Column, Text
+from sqlalchemy import MetaData, Table, Column, String
from sqlalchemy.pool import QueuePool, SingletonThreadPool
from sqlalchemy.schema import (PrimaryKeyConstraint, Index, AddConstraint,
CreateIndex)
@@ -120,7 +120,7 @@
'primary_key': None}
table_creation = []
for col_name in table_def['columns']:
- table_creation.append(Column(col_name, Text()))
+ table_creation.append(Column(col_name, String(255)))
if table_def['primary_key']:
table_creation.append(PrimaryKeyConstraint(
*table_def['primary_key']))

The problems here occurred with the PrimaryKey we put over uuid/name and name/option columns.
This is problematic because MySQL does not allow keys over Text columns (because these could be of arbitrary length) with the MyISAM backend.

We need to adapt this patch to only make uuid/name and name/option to be String(255), because the values might still be of "unlimited" (read: very long) length, for example SP metadata contents.

Patch available in https://pagure.io/ipsilon/pull-request/140

owner: => puiterwijk
patch_available: 0 => 1
status: new => accepted

Metadata Update from @puiterwijk:
- Issue assigned to puiterwijk

Metadata Update from @t0xic0der:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
Normal
defect
Installer
1.1.1
0
1
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.