You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repository has a number of database related packages that are spread out across the code base and I'm looking to consult with the team about consolidating them.
The other major problem with this implementation is that the business logic is too tightly coupled to the DB type and syntax with no layer of abstraction in between. This would make changing to another form of data persistence an involved task.
Discuss the roles of each of the identified packages, identify any additional packages that are database related.
Come to a consensus about the consolidation approach for the identified packages.
Move packages into the decided structure
Refactor all dependant packages
Acceptance Criteria
Database related packages are restructured as per the consensus arrived to here in this issue.
Notes
This isn't a witch hunt, or in any way a criticism of implementation choices made in the past, I'm certain every contributor that placed these packages where they are currently had legitimate reasons for doing so. The purpose of this issue is to get the code base into a state where it is more easily understood by a new developer (like me 😄 ), and consolidate related packages where it makes sense.
Future Steps
Any additional database based functionality should adhere to the conventions established here in this issue.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Problem
This repository has a number of database related packages that are spread out across the code base and I'm looking to consult with the team about consolidating them.
The other major problem with this implementation is that the business logic is too tightly coupled to the DB type and syntax with no layer of abstraction in between. This would make changing to another form of data persistence an involved task.
Packages I've identified are:
Implementation
Acceptance Criteria
Database related packages are restructured as per the consensus arrived to here in this issue.
Notes
This isn't a witch hunt, or in any way a criticism of implementation choices made in the past, I'm certain every contributor that placed these packages where they are currently had legitimate reasons for doing so. The purpose of this issue is to get the code base into a state where it is more easily understood by a new developer (like me 😄 ), and consolidate related packages where it makes sense.
Future Steps
Any additional database based functionality should adhere to the conventions established here in this issue.
The text was updated successfully, but these errors were encountered: