Move Revision enum from schemas/common.py

[franciszekjob]

Feature Request

Currently Revision is stored in schemas/common.py. There are circular import errors when storing it in models/typed_data.py. Revision should be moved to either separate file or models/typed_data.py after solving circular import errors.

[ScottyDavies]

Hello @franciszekjob can i work on this?

[franciszekjob]

Hey @ScottyDavies, you're welcome to open a PR for it.

[ScottyDavies]

out of curiosity do contributors get paid? @franciszekjob

[franciszekjob]

@ScottyDavies At this moment, we do not sponsor this issue nor any other issues through OnlyDust.

[KevinMB0220]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I have experience in all the languages ​​used in the issue, so it would be easier for me to achieve it.

How I plan on tackling this issue

To resolve the circular import issue when moving Revision to models/typed_data.py, you can refactor the imports by placing any problematic imports within functions or methods to delay them, thus breaking the circular dependency. Alternatively, you could move the Revision class into its own module (e.g., models/revision.py), allowing both schemas/common.py and models/typed_data.py to import it without issues. This isolates the Revision class, avoiding direct dependencies between the two modules.

[DioChuks]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

Full-Stack Engineer:
Deep Understanding of Module Structures:
My experience with multiple languages like Python and JavaScript equips me with the ability to understand and refactor module structures effectively. Circular imports are a common challenge in both Python and JavaScript, and my problem-solving skills can help identify the best approach, whether through restructuring or using lazy imports.

Leverage: Use my knowledge of module systems in Python and TypeScript to identify where the circular dependencies are occurring and determine the best way to isolate the Revision enum without breaking functionality.

Experience in Object-Oriented Programming:
My Python and PHP background implies a strong foundation in object-oriented programming, which will help me think about modularity and separation of concerns. This can be crucial when moving the Revision enum to a dedicated file or reorganizing the project structure.

Leverage: Apply object-oriented design principles to reorganize the project into a more modular structure. By separating shared components into dedicated modules, you can avoid circular imports and improve code maintainability.

Problem Solving and Refactoring Expertise:
Given my strength in problem solving, i'll be able to quickly identify patterns of redundancy or inefficiency in the current structure. Refactoring the circular import issue requires both technical knowledge and creative problem-solving to ensure the solution is clean and scalable.

Leverage: Apply problem-solving techniques to identify whether breaking the circular dependency through restructuring or using local imports is the most effective solution. My ability to debug complex issues will help streamline this process.

Conclusion:
With my background in Python, PHP, JavaScript, TypeScript, and strong problem-solving abilities, I also have a degree in computer science, i am well-equipped to refactor the project in a clean and efficient manner. I'll be able to isolate and move the Revision enum while solving circular imports, ensuring the codebase remains maintainable and scalable for future growth.

How I plan on tackling this issue

To address the issue of moving the Revision enum from schemas/common.py while solving the circular import errors, here’s how I would approach the problem:

Firstly, It's to Understand the Cause of Circular Import:
Circular Import: Circular imports occur when two or more modules depend on each other directly or indirectly. In this case, it seems that both models/typed_data.py and schemas/common.py depend on each other, which is causing the circular import issue.
Revision Enum: Revision is an enum that is used in both schemas/common.py and models/typed_data.py, and moving it requires restructuring to avoid circular dependencies.
Secondly, to investigate Import Dependencies:
Check Dependencies: I will Inspect both models/typed_data.py and schemas/common.py to see where and how Revision is being imported and used. This will give me insight into how the circular import is created.
Identify Other Dependencies: I'll check for other dependencies between these modules that might also contribute to the circular import.
I have an option for resolving the circular import issue while moving the Revision enum:

Moving Revision to a Separate Module
Creating a New File: Move the Revision enum to a new file (e.g., schemas/revision_enum.py or models/revision_enum.py). This isolates the enum in its own module, reducing the risk of circular imports:

schemas/revision_enum.py

from enum import Enum

class Revision(Enum):
DRAFT = "draft"
FINAL = "final"
I can import Revision Where Needed: After moving Revision, I can import it in both models/typed_data.py and schemas/common.py:

models/typed_data.py

from schemas.revision_enum import Revision
This method keeps Revision separate and reduces complexity, which may eliminate the circular import.

[franciszekjob]

@DioChuks please open a PR if you want to contribute, thanks.

[manicdon7]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

With a background in software development, particularly in Python and modular application design, I have experience managing complex project structures and resolving issues like circular dependencies. I also have a good understanding of database schemas, ORM (Object-Relational Mapping), and Python packaging, which can be useful in solving this problem.

How I plan on tackling this issue

Identify Circular Dependencies:

First, I would trace the exact point of circular dependency between schemas/common.py and models/typed_data.py. This will help identify the imports that are causing the issue.
Evaluate Dependencies:

If the Revision class or function is being used in both files, it is crucial to understand where and how it is being referenced.
I would analyze whether both files are heavily interdependent or if only a few functions/classes from each module are causing the problem.
Refactor to Solve Circular Imports:

Option 1: Create a Separate Module: One of the most effective solutions for resolving circular dependencies is moving the Revision class or function to a new, dedicated module (e.g., common/revision.py). This will allow both schemas/common.py and models/typed_data.py to import Revision without directly depending on each other.

Option 2: Lazy Import or Intra-function Import: If refactoring is not feasible, I would use lazy imports (importing inside functions instead of globally) to break the circular reference while keeping the existing structure intact.

Test the Changes:

After implementing the solution, I would run the project’s unit and integration tests to ensure that the refactoring resolves the circular import issue without introducing new bugs.
Code Review and Documentation:

I would document the changes clearly, especially if the Revision class is moved to a separate module. This ensures that other developers working on the project understand the new structure.
Submitting the changes for code review to get feedback and ensure the refactoring aligns with the overall codebase.

[onlydustapp]

The maintainer franciszekjob has assigned manicdon7 to this issue via OnlyDust Platform.
Good luck!