Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reset SQL migrations #119

Merged
merged 4 commits into from
Jul 13, 2023
Merged

Reset SQL migrations #119

merged 4 commits into from
Jul 13, 2023

Conversation

mrferris
Copy link
Collaborator

Creates all tables with their needed columns, rather than adding columns later on. Will require a DB wipe.

Copy link
Member

@pipermerriam pipermerriam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so sorry if you already had plans to add these.

migration/src/m20230511_104804_create_node.rs Show resolved Hide resolved
migration/src/m20230511_104814_create_content.rs Outdated Show resolved Hide resolved
migration/src/m20230511_104814_create_content.rs Outdated Show resolved Hide resolved
migration/src/m20230511_104814_create_content.rs Outdated Show resolved Hide resolved
migration/src/m20230511_104830_create_content_audit.rs Outdated Show resolved Hide resolved
.primary_key(),
)
.col(ColumnDef::new(KeyValue::RecordId).integer().not_null())
.col(ColumnDef::new(KeyValue::Key).binary().not_null())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need two indexes here:

  • an index on (record_id, key) unique index. which enforces the constraint and allows quick querying of all the keys for a given record_id.
  • an index on only key so that we can lookup all the records with a given key.

@mrferris mrferris force-pushed the reset-migrations branch 2 times, most recently from 6476c91 to b0ac823 Compare May 12, 2023 20:19
@mrferris
Copy link
Collaborator Author

so sorry if you already had plans to add these.

Hadn't thought about most of these indices/queries, so thanks!

Currently seeing sea orm generating invalid sql syntax when creating non-unique indices (which is why they're commented out here):


CREATE TABLE "content" (
      "id" serial NOT NULL PRIMARY KEY,
      "protocol_id" integer NOT NULL,
      "content_key" bytea NOT NULL,
      "content_id" bytea NOT NULL,
      "first_available_at" timestamp with time zone NOT NULL,
      CONSTRAINT "idx-unique-id-protocol-and-key" UNIQUE ("protocol_id", "content_key", "content_id"),
      CONSTRAINT "idx-unique-protocol-and-key" UNIQUE ("protocol_id", "content_key"),
      CONSTRAINT "idx-unique-protocol-and-id" UNIQUE ("protocol_id", "content_id"),
      CONSTRAINT "idx-available-and-protocol" ("first_available_at", "protocol_id")
    )

Error: Execution Error: error returned from database: syntax error at or near "("

@mrferris mrferris self-assigned this May 15, 2023
@pipermerriam
Copy link
Member

I think I ran into this same issue, any chanced you looked upstream to see if this is a known sea-orm issue?

Lets move forward at least with the unique ones and open an issue to figure out the non-unique ones at a later date.

@mrferris mrferris mentioned this pull request Jun 9, 2023
2 tasks
@mrferris mrferris marked this pull request as ready for review June 20, 2023 20:03
@mrferris mrferris merged commit 8553fa8 into ethereum:master Jul 13, 2023
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants