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

Feature/schema function independent #102

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

salamonpavel
Copy link
Contributor

@salamonpavel salamonpavel commented Dec 1, 2023

As part of this pull request, DBSchema has been made an optional constructor parameter of DBFunction. Additionally, the logic for deriving the functionName has been updated.

Separating the concerns of function name derivation between DBSchema and DBFunction is beneficial for a few reasons:

  1. Decoupling: By separating these concerns, DBFunction doesn't need to know the details of how the schema name is derived. It just needs to know that it can get a schema name from DBSchema. This decoupling makes the code more modular and easier to change. It also means that changes to how the schema name is derived won't affect the DBFunction class, and vice versa.

  2. Consistency: By centralizing the logic for function name derivation in DBFunction, you ensure that the same logic is used consistently across all instances of DBFunction. This can help prevent bugs and inconsistencies that might arise if different parts of the codebase were deriving function names in different ways.

  3. Flexibility: The DBFunction class can be used with or without a DBSchema. By separating the concerns of function name derivation, you allow for greater flexibility in how DBFunction instances are created.

  4. Code Reusability: The logic for deriving the function name is encapsulated in DBFunction. This means that the same logic can be reused for all DBFunction instances, regardless of whether they have a DBSchema or not.

  5. Ease of Testing: With separated concerns, it's easier to write unit tests for each class. You can test the schema name derivation logic in DBSchema independently of the function name derivation logic in DBFunction.

Separating the concerns of function name derivation between DBSchema and DBFunction leads to more modular, consistent, flexible, and testable code.

Copy link

github-actions bot commented Dec 1, 2023

JaCoCo code coverage report - scala 2.12.17

File Coverage [40.92%]
DBSchema.scala 100% 🍏
DBFunction.scala 32.96%
Total Project Coverage 51.95% 🍏

Copy link

github-actions bot commented Dec 1, 2023

JaCoCo code coverage report - scala 2.11.12

File Coverage [49.58%]
DBSchema.scala 100% 🍏
DBFunction.scala 42.26%
Total Project Coverage 51.8% 🍏

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

1 participant