Improvements, and plans for the future.

[myusko]

@michaelbukachi, we should collect all suggestions/thoughts from the community, on which things we should focus on in the future, which features we should implement, and what type of improvements the community would like to see sqlalchemy-mixins.

Any comments/suggestions from the community are welcomed!

[michaelbukachi]

At the moment, we are working on SQLAlchemy 1.4/2.0 support. There are a couple of PRs open but they haven't been thoroughly tested.

[myusko]

At the moment, we are working on SQLAlchemy 1.4/2.0 support. There are a couple of PRs open but they haven't been thoroughly tested.

Awesome! I'll go through PR's tomorrow, and also plan to write my thoughts regarding improvements, etc.

[myusko]

Ok, from my side I want to share the next things, to consider them as new features/improvements.

• Add mkdocs support, it has a nice material UI and will allow us to have new stylish documentation.
• Add type hinting(?)
• Clean up the repository(probably some refactoring), and all docstrings should be updated/added(?)
• Decide which Python version we won't support(?)

Also, this list will be updated, once new ideas will arrive.

cc @michaelbukachi

[michaelbukachi]

Thanks @myusko. I'll add to the list as soon as I'm home.

[michaelbukachi]

To continue where @myusko left off,

• For the python versions, the current minimum is 3.5. Apparently, that's the minimum support version on actions. See this failed action. So currently, the minimum version is 3.5
• We should definitely prioritize type hinting and add mypy checks to the actions as well. This will improve readability and code navigation.
• Come up with a better syntax for conjunction operators (AND, OR). There's a PR open but I feel that it can be improved. We should strive for the simplicity the creator of the library envisioned.

[myusko]

@michaelbukachi I totally agree that mypy should be added, let's create an issue for it, also in the documentation, we also should mention that the minimum Python version is 3.5.

Regarding, the conjunction operators, I also agree, and definitely, we should strive for simplicity, as you mentioned.

[michaelbukachi]

@myusko I've updated the readme.
If I get time during the day, I'll create the ticket and the details of what needs to be done for mypy ticket.

[SK-FComputer]

@michaelbukachi you should specify that version needs to be 3.5 and above
Current docs reads like it is only 3.5

[myusko]

@SK-FComputer I'll update this, thank you!

[aurthurm]

Are there plns to support async sqlalchemy i future?

[ZhymabekRoman]

Are there plns to support async sqlalchemy i future?

Yeah, same question

[michaelbukachi]

@aurthurm @ZhymabekRoman async is quite stable on SQAlchemy and is still heavily under development. We'd rather wait till it's completely stable rather than do a lot of fire fighting with each SQLAlchemy release.

[aurthurm]

@aurthurm @ZhymabekRoman async is quite stable on SQAlchemy and is still heavily under development. We'd rather wait till it's completely stable rather than do a lot of fire fighting with each SQLAlchemy release.

@michaelbukachi we can have an async branch for async functionality and not use master branch so that we can start brainstorming the async functionality. Those interested in using the features can use as we wait for the stable version.

WIll be happy to share how i refactored the mixins to suport async functinality. My approach might not have been the best but am willing to put it on the table and open for suggestions.

[michaelbukachi]

Hey, @aurthurm sure thing. Looking forward to your PR!

[aurthurm]

Hey, @aurthurm sure thing. Looking forward to your PR!

Hie @michaelbukachi, I have added an issue and a pull request to this.

Awaiting your insights