-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
Ability to discover PostgreSQL enums #24
Conversation
Add enum type for writer
Fix a few typos I found while digging through the source code
to allow the ` #[derive(sqlx::FromRow, Debug)]` to be used to derive an sqlx row for handling PostgreSQL enums
I don't really think it completely resolved the issue @billy1624 can you point out the missing pieces? |
I think there are some misunderstanding. To make things clear I will explain it in steps Tasks
@tyt2y3 correct me if something seems off |
Hey @charleschege, you need any help? |
Sorry, yesterday I had some engagements. I am working on this today. From what I understand:
Correct me if I am wrong |
Add documentation on types Output the result by calling `discover_enum` on `SchemaDiscovery`
Add missing documentation for the added types for enum creation
Write into SQL and then parse the raw SQL asserting that all discovered enums are the same as their raw SQL queries
Hey @charleschege, I have tested some marginal cases where the enum variants contain special characters such as I run This is what I get. So basically joining all variants using
|
@billy1624 Yeah! I agree that is an extreme case. I will rewrite the select statement creation and parser |
Can you tick the box and give write access to maintainers? Just now I want to fix the CI errors but I don't have the permission to push commits. The checkbox should be around the right corner on this page. |
Done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A proper test case would be like what tests/live/postgres/src/main.rs
does. You can add your test cases to there directly.
Basically you write the TypeCreateStatement
statement and run it on Postgres to create the enum. Then, you run the enum discover and writer you just wrote. Finally, you assert the discovered TypeCreateStatement
match the originally TypeCreateStatement
that you write by hand at the very beginning.
Remove redundant module postgres_enum from the tests dir
…CI runs successfully
dbb03b0 seems to solve all the requirements to discover enums even in cases where enums have special characters. @tyt2y3 @billy1624 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tests/writer/postgres_enum has been removed and tests moved to the tests/live/postgres directory
@tyt2y3 @billy1624 what else is needed to get this PR merged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even easier to read. Thanks!
Hey @tyt2y3, please the overall structure now |
Ready for review @tyt2y3 |
@billy1624 Thanks for reviewing the code and making some changes. Through some improvements you made I have learnt more about the internals of this repository. Thanks again. |
No problems! Please correct me if I break your original code |
@billy1624 Sometimes assertion fails on the enums. If they are re-arranged, assertion always panics. I had been able to achieve some correctness by always sorting the structure first. I suppose that was not important to begin with 😂. But what if I wrote some code as a user and needed to do assertion on the enum, even though the enums are the same, comparison would fail due to their ordering, how would this be done to ensure that assertion always succeeds? |
To provide an example output of this:
|
pub fn query_enums(&self) -> SelectStatement { | ||
Query::select() | ||
.column((PgType::Table, PgType::TypeName)) | ||
.column((PgEnum::Table, PgEnum::EnumLabel)) | ||
.from(PgType::Table) | ||
.inner_join( | ||
PgEnum::Table, | ||
Expr::tbl(PgEnum::Table, PgEnum::EnumTypeId).equals(PgType::Table, PgType::Oid), | ||
) | ||
.order_by((PgType::Table, PgType::TypeName), Order::Asc) | ||
.order_by((PgEnum::Table, PgEnum::EnumLabel), Order::Asc) | ||
.take() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The generated Vec<EnumDef>
will be in ascending order of typename and variants of it will also be in ascending order.
let create_enum_stmt = Type::create() | ||
.as_enum(Alias::new("crazy_enum")) | ||
.values(vec![ | ||
Alias::new("Astro0%00%8987,.!@#$%^&*()_-+=[]{}\\|.<>/? ``"), | ||
Alias::new("Biology"), | ||
Alias::new("Chemistry"), | ||
Alias::new("Math"), | ||
Alias::new("Physics"), | ||
]) | ||
.to_string(PostgresQueryBuilder); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The expected result should be in the same order, i.e. ascending order
Yes, I notice the issue and understand why you used the sorting method. I think it's fine as long as the generated result is deterministic, i.e. sorted in a particular order. Then, user can always rearrange the expected output while keeping the semantic to match the generated output. |
* Correct type from Alias::new("ploygon") to Alias::new("polygon") Add enum type for writer * Add type * Add support for PostgreSQL types Fix a few typos I found while digging through the source code * Add tests for checking the correctness of PostgreSQL enum parsing and processing * Gate `PgEnum` and its impl block under the `sqlx` feature to allow the ` #[derive(sqlx::FromRow, Debug)]` to be used to derive an sqlx row for handling PostgreSQL enums * Add support for fetching enums * Move types into types files under postgres::def::Type Add documentation on types Output the result by calling `discover_enum` on `SchemaDiscovery` * Add method to parse a raw SQL create query for enum creation Add missing documentation for the added types for enum creation * Test case to discover all the enums in a given database schema Write into SQL and then parse the raw SQL asserting that all discovered enums are the same as their raw SQL queries * Solve issues with github actions not detecting types * Add feature flag for new enum type and associated functions * Switch to using re-exported sqlx types within sea-schema * Fix CI errors * Support enums with crazy names that include special characters * Add support for ordered Vecs * Add tests for discovery of enums Remove redundant module postgres_enum from the tests dir * Ensure a custom enum type is dropped first from the database so that CI runs successfully * Refactoring * Ensures the writer derives the enum name from the EnumDef * Refactoring * Refactoring * Refactoring * Testing enum column... * Refactoring * Refactoring * Refactoring * Fix test * Refactoring * Refactoring * Refactoring * Cleanup Co-authored-by: Billy Chan <ccw.billy.123@gmail.com>
This PR attempts to close issue #22