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

Ab/sqlite #2284

Draft
wants to merge 84 commits into
base: main
Choose a base branch
from
Draft

Ab/sqlite #2284

wants to merge 84 commits into from

Conversation

imabdulbasit
Copy link
Contributor

This PR adds support for sqlite

  • Updates the hotshot-query-service which includes the sqlite support.
  • Adds separate migrations for PostgreSQL and SQLite.
  • Some data types in the state table columns have been updated to JSONB, and a separate migration updates those data types. This was necessary because SQLite does not support BYTEA or arrays, so a BLOB column is used instead. This change unifies the queries across databases.
  • Introduces a feature flag, embedded-db, which activates SQLite (embedded-db). If not provided, postgres is used by default.
  • Updates workflows to include a job for testing PostgreSQL, as all-features includes embedded-db and tests with SQLite.
    -Updates the just recipes to enable local testing with both SQLite and PostgreSQL.

Note: SQLite sometimes lacks support for basic SQL syntax that one might expect, such as ORDER BY (col1, col2...) DESC. Instead, we use ORDER BY col1 DESC, col2 DESC to ensure compatibility with both PostgreSQL and SQLite.

.github/workflows/slowtest.yaml Outdated Show resolved Hide resolved
exit_on_skipped: true

sequencer2:
command: sequencer -- http -- catchup -- status
Copy link
Member

Choose a reason for hiding this comment

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

So these are all running the same binary with sqlite storage. Ideally, we would just have one demo, and we would run the query nodes with postgres and the other nodes with sqlite, as we will do in production.

The only way I can think of to get these binaries built at the same time with different feature flags is to move sequencer/main.rs into two separate crates. So we can have sequencer-sqlite/Cargo.toml and sequencer-postgres/Cargo.toml, each of which import sequencer with different feature flags. We can move most of the logic from main.rs into the sequencer library crate so it isn't duplicated.

This is a bit ugly, maybe there's a better way, but the point is we need to find out how to get two simultaneous executables with different names and different feature flags, so that we can use them at the same time in a demo, and also so that we can build a sequencer docker image that includes both of these binaries (this I think will be the easiest way for us to ship this to node operators)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The Cargo features are additive, so the embedded-db feature is automatically enabled for sequencer-postgres when running cargo build.

rust-lang/cargo#674 (comment)

Copy link
Contributor Author

@imabdulbasit imabdulbasit Nov 19, 2024

Choose a reason for hiding this comment

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

Two options come to mind: use the cfg directive instead of a feature, or remove these two crates from the workspace or maybe only the sqlite crate

sequencer/src/persistence/sql.rs Outdated Show resolved Hide resolved
marketplace-solver = { path = "../marketplace-solver" }
num_enum = "0.7"
portpicker = { workspace = true }
rand = { workspace = true }
rand_chacha = { workspace = true }
rand_distr = { workspace = true }
sequencer-utils = { path = "../utils" }
sequencer-utils = { path = "../utils", features = ["testing"] }
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we do without the "testing" feature in the build dependencies?

justfile Outdated
cargo clippy --workspace --all-features --all-targets -- -D warnings
@echo 'features: "testing"'
cargo clippy --workspace --all-features --features testing -- -D warnings
Copy link
Collaborator

Choose a reason for hiding this comment

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

this has all-features and testing

justfile Outdated
@echo 'features: "all"'
cargo nextest run --locked --workspace --all-features --verbose {{args}}
@echo 'features: "testing"'
cargo nextest run --locked --workspace --features testing --verbose {{args}}
Copy link
Collaborator

@sveitser sveitser Nov 19, 2024

Choose a reason for hiding this comment

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

I don't think we need to explicitly activate the testing feature to compile the tests. It should be activated via dev dependencies.

For me the logs are always truncated if I download them from the
browser.
--workspace-remap $PWD $(if [ "${{ matrix.version }}" == "2" ]; then echo " smoke"; fi)
timeout-minutes: 40
timeout-minutes: 20
Copy link
Collaborator

Choose a reason for hiding this comment

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

Based on the fact that this seems to fail because consensus gets stuck due to the upgrade that happens usually before 120 blocks. Shouldn't we fail this earlier instead of waiting for 20 minutes?

block: height=114, version=0.2
block: height=114, version=0.2
block: height=115, version=0.2
block: height=115, version=0.2
  TRY 1 SLOW [>240.000s] tests::integration upgrades::test_upgrade
block: height=115, version=0.2
block: height=115, version=0.2
  TRY 1 SLOW [>360.000s] tests::integration upgrades::test_upgrade
  TRY 1 SLOW [>480.000s] tests::integration upgrades::test_upgrade 
  ...

cache-all-crates: true
cache-provider: buildjet

- name: Build and archive tests
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we are just building the same test binaries twice and giving them two different names. This doesn't appear to select sqlite tests, it just gives it an sqlite name. If so, we should just do the build once.

Copy link
Contributor

Choose a reason for hiding this comment

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

I may have answered my own question elsewhere, but if we are using --all-features in order to specify embedded-tb can we not specify feature embedded-db explicitly?

@echo 'Omitting slow tests. Use `test-slow` for those. Or `test-all` for all tests.'
@echo 'features: "all"'
cargo nextest run --locked --workspace --all-features --verbose {{args}}
cargo nextest run --locked --workspace --verbose {{args}}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we running all the tests twice now?


- name: Build Espresso Dev Node
# Espresso Dev Node currently requires testing feature, so it is built separately.
run: |
cargo build --locked --release --features testing --bin espresso-dev-node
cargo build --locked --release --features "testing embedded-db" --bin espresso-dev-node
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we explicitly specify the embedded-db features everywhere? I think in other places we are just specifying --all-features which isn't clear. Especially since we were using --all-features previously (I think).

@@ -32,5 +32,8 @@ jobs:
- name: Format Check
run: cargo fmt -- --check

- name: Check
- name: Check (embedded-db)
Copy link
Contributor

Choose a reason for hiding this comment

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

Confused here too. Won't --all-features + --all-targets lint everything? If so, why run clippy a second time?

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.

4 participants