apache / superset

Apache Superset is a Data Visualization and Data Exploration Platform
https://superset.apache.org/
Apache License 2.0
62.45k stars 13.73k forks source link

Duplicate Referential Constraint in Oracle Database Migration Script #30591

Open SuWenCheng opened 1 week ago

SuWenCheng commented 1 week ago

Bug description

I encountered an issue while using Apache Superset with an Oracle database. During the database migration process, an error ORA-02274: duplicate referential constraint specifications occurs. This error is caused by the migration script automatically generated by Superset, which includes duplicate foreign key constraints.

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

dosubot[bot] commented 1 week ago

Hey there, @SuWenCheng! I'm here to help you with any bugs, questions, or contributions you have. Let's tackle this challenge together!

A similar issue was reported and closed in the Superset repository. The problem was caused by duplicate foreign key constraints in the migration script, leading to the ORA-02274 error. The suggested solution is to ensure that the foreign key constraint is defined only once in the migration script.

Here's the corrected version of the script:

op.create_table(
    "metrics",
    sa.Column("id", sa.Integer(), nullable=False),
    sa.Column("metric_name", sa.String(length=512), nullable=True),
    sa.Column("verbose_name", sa.String(length=1024), nullable=True),
    sa.Column("metric_type", sa.String(length=32), nullable=True),
    sa.Column(
        "datasource_name",
        sa.String(length=255),
        nullable=True,
    ),
    sa.Column("json", sa.Text(), nullable=True),
    sa.Column("description", sa.Text(), nullable=True),
    sa.ForeignKeyConstraint(["datasource_name"], ["datasources.datasource_name"]),
    sa.PrimaryKeyConstraint("id"),
)

This solution removes the redundant sa.ForeignKey definition and keeps only the sa.ForeignKeyConstraint [1].

To continue talking to Dosu, mention @dosu.

SuWenCheng commented 1 week ago

It seems that there are many different compatibility issues with Oracle in various migration scripts. Do I have to manually fix each one individually? Is there a better way to handle this?

dosubot[bot] commented 1 week ago

You might not need to manually fix each issue individually. Here are some strategies to handle Oracle compatibility issues in migration scripts more efficiently:

  1. Automated Testing: Set up automated tests to run migration scripts against an Oracle database. This can help identify issues early and ensure compatibility.

  2. Custom Migration Scripts: Create custom migration scripts tailored for Oracle. This can be done by overriding problematic scripts with Oracle-specific logic.

  3. Use SQLAlchemy and Alembic Features: Leverage SQLAlchemy's and Alembic's features to handle database-specific constraints and features. This includes using reflection and operations that are compatible with Oracle.

  4. Centralize Fixes: If you encounter a common pattern causing issues, centralize the fix in a utility function or shared script that can be reused across different migrations.

  5. Community Contributions: Check if there are community-contributed patches or scripts that address Oracle compatibility issues. These can often be integrated into your workflow.

By implementing these strategies, you can streamline the process and reduce the need for manual fixes.

To continue talking to Dosu, mention @dosu.