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

Accept type_options when testing type casts, making it possible to test every type cast #869

Open
silentninja opened this issue Dec 7, 2021 · 10 comments
Labels
affects: dx Related to developer experience affects: technical debt Improves the state of the codebase needs: implementation specs We need clarity on HOW we'll implement it from a technical perspective needs: unblocking Blocked by other work type: maintenance Refactoring and technical debt payoff work: db-layer Related to SQL or PL/pgSQL
Milestone

Comments

@silentninja
Copy link
Contributor

Problem

Currently, test case fixture(db/tests/types/operations/test_cast.py:MASTER_DB_TYPE_MAP_SPEC) used to test casting of a column type do not seem to accept type options, so this makes it not possible to test certain type casts like URI to CHAR(CHAR without type_options defaults to 1 character), making the test cases incomplete.

Proposed solution

TARGET_DICT dictionary should accept type_options for each type.

@silentninja silentninja added type: enhancement New feature or request good first issue Everything in "Help wanted", PLUS being relatively easy and straightforward to implement. help wanted Community contributors can implement this affects: technical debt Improves the state of the codebase work: database ready Ready for implementation labels Dec 7, 2021
@jjram20
Copy link

jjram20 commented Dec 23, 2021

Hi, I would like to help in this problem.

@silentninja silentninja added status: started and removed ready Ready for implementation labels Dec 23, 2021
@silentninja
Copy link
Contributor Author

@jjram20 Thanks! I have assigned it to you.

@mathemancer
Copy link
Contributor

@jjram20 Hey, are you still making progress on this issue?

@mathemancer
Copy link
Contributor

Unassigning due to lack of progress / feedback.

@Jayitha
Copy link

Jayitha commented Apr 27, 2022

Hi, I'd like to work on this issue.

@kgodey
Copy link
Contributor

kgodey commented Apr 27, 2022

Sure, go ahead @Jayitha

@kgodey kgodey modified the milestones: [06.2] 2022-04 improvements, [08.1] 2022-05 improvements May 2, 2022
@Jayitha
Copy link

Jayitha commented May 10, 2022

Hi,

Sorry for the delay, I spent some time playing around with the codebase. I think the whole types system is pretty neat! especially how it renders in Postgres. I created a PR for this issue to get things going. I currently only included support to provide type options for the target type. I'd actually like to work on this issue in tandem with #1138 if possible?

@silentninja
Copy link
Contributor Author

Sure @Jayitha, that shouldn't be a problem

@kgodey kgodey modified the milestones: [08.1] 2022-05 improvements, Unprioritized Jun 1, 2022
@kgodey kgodey added ready Ready for implementation and removed good first issue Everything in "Help wanted", PLUS being relatively easy and straightforward to implement. status: started labels Sep 1, 2022
@github-actions
Copy link

github-actions bot commented Apr 6, 2023

This issue has not been updated in 90 days and is being marked as stale.

@github-actions github-actions bot added the stale label Apr 6, 2023
@rajatvijay rajatvijay removed the stale label Apr 10, 2023
@seancolsen seancolsen added work: backend Related to Python, Django, and simple SQL and removed work: database labels Dec 5, 2023
@mathemancer mathemancer added affects: dx Related to developer experience type: maintenance Refactoring and technical debt payoff needs: requirements The problem is clear and worth solving, but we're not yet sure of the best solution needs: implementation specs We need clarity on HOW we'll implement it from a technical perspective and removed type: enhancement New feature or request help wanted Community contributors can implement this ready Ready for implementation needs: requirements The problem is clear and worth solving, but we're not yet sure of the best solution labels Jan 4, 2024
@mathemancer
Copy link
Contributor

We should avoid doing this until we've moved the type casting functions to the DB, and then also the type casting test suite.

@mathemancer mathemancer added needs: unblocking Blocked by other work work: db-layer Related to SQL or PL/pgSQL and removed work: backend Related to Python, Django, and simple SQL labels Jan 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects: dx Related to developer experience affects: technical debt Improves the state of the codebase needs: implementation specs We need clarity on HOW we'll implement it from a technical perspective needs: unblocking Blocked by other work type: maintenance Refactoring and technical debt payoff work: db-layer Related to SQL or PL/pgSQL
Projects
No open projects
Development

No branches or pull requests

7 participants