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

DatabaseAdapter value object #1671

Merged
merged 19 commits into from
Aug 30, 2023
Merged

DatabaseAdapter value object #1671

merged 19 commits into from
Aug 30, 2023

Conversation

fidel
Copy link
Contributor

@fidel fidel commented Aug 29, 2023

Btw. it enables use of trident mysql adapter

fidel and others added 19 commits August 29, 2023 13:42
It's meant to replace string literals across codebase, especially across
several case statements.
This design is closer to actual use–case. VO will be instantiated based
on string literal containing adapter name.
Use of ArgumentError might be tempting, but it should be used in a bit
different context. Implementing specific error is a bit nicer approach.
When trying to instantiate unsupported adapter, exception will be
raised. No need to call class to make yet another string comparison.
Object is always a better abstraction than string.
It can have less responsibilities now.
Not to confuse each other.
DatabaseAdapter can now receive data_type as argument. Each specific
adapter contains list of allowed data types and won't allow use of
unsupported one.
However, on the class level it will be hard to determine current
adapter. Let's display all the available types (PostgreSQL has biggest
set of such) and fail further if incompatible type is used.
Same features, less verbose implementation. Introducing new adapter type
should be easier now.

Co-authored-by: Piotr Jurewicz <[email protected]>
Maybe it would make sense, but verification of data type would require a
lot of gymnastics and we see no value in it.

Co-authored-by: Piotr Jurewicz <[email protected]>
We don't need to reflect specific adapter naming. Default driver for
MySQL in rails 7.1 will be Trilogy. It's a detail not in our scope of
interest. We only need to be sure which data types are allowed for given
database.

Co-authored-by: Piotr Jurewicz <[email protected]>
It will be a default in Rails 7.1. In our scope it's yet another MySQL
adapter and check only matters when allowing specific data types
supported by database itself.

Co-authored-by: Piotr Jurewicz <[email protected]>
Template directory depends on used adapter type, so it's a viable place
to keep this information close to the adapter itself. Yet another case
statement removed.
@fidel fidel merged commit c7d80d1 into master Aug 30, 2023
@fidel fidel deleted the database_adapter_vo branch August 30, 2023 12:03
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.

1 participant