The Path to 1.0

[channelcat]

To help contributors understand the current state of the project and its goals, it would be great to have a set of issues to tackle to help hit an initial release. Here's some suggestions - I'd be happy to work on any of these, though I think the code cleanup should be done by @henadzit so he can feel confident when removing the quality warning :)

MVP

MySQL + MSSQL + Oracle Support

I'd argue that the goal should be to support all major databases that tortoise supports.
By package popularity, they're all pretty widely used. Async adoption is pretty low (mysql connector includes async support within, so it's hard to tell), but maybe we can help change that!

Stats:

• mysql-connector-python 10.4M/wk
• pymssql - 6.5M/wk
• psycopg2 - 6M/wk
• mysqlclient - 4.5M/wk
• asyncpg - 4.5M/wk
• aiosqlite - 4M/wk
• psycopg - 4M/wk
• oracledb - 3.3M/wk
• asyncmy - 55K/wk (not the official connector)
• asyncodbc - 1K/wk

In-Depth Documentation

Full documentation around setup, supported features, testing, etc. See Django Migrations and other migration tool docs online for inspiration

End-to-end Tests for Postgres/MySQL/MSSQL/Oracle

This can be done with docker (and more simply with compose)

Code Review and Cleanup Pass

It's stated in the Readme that the code is AI generated and not final. Someone should run through it and create issue tickets for any large changes that need to be made so this project can rightfully be rid of the message :).

Contribution Guide

Something basic to help contributors know what the expected process is to make a change to the codebase, testing tools, coding standards, and philosophies.

Usability Pass

Go through all use cases of the tooling and sure all common issues, gotchas, and foot-guns are documented and have clear error messages that guide the user towards the fix.

Contact tortoise-orm Maintainers

Talk to tortoise-orm maintainers about what it would take to list this as an official migration tool or possibly succeed aerich if they're open to the idea. IMO It would be better to do this before launch in case they suggest any major changes.

Stretch Goals

Extended CLI Tooling

Ability to preview changes, dry run migrations, and possibly squash migrations?

Example Projects

Make example projects with migration scripts or custom CLIs

Project Configurability

Create a way for the ORM to be configured for the project using something like pyproject.toml instead of passing the tortoise config to every command. This could also open the door for more configuration options.

PyPI Release CI

To help any future maintainers publish and take advantage of Github's release feature, it would be great to set up a Github Action to push to PyPI on release.

Default Values

When a non-null field is added after a table is created, prompt the user for a default value

[henadzit]

The goals sound good to me! Thank you for writing this down! A few more things from me:

• We would also probably want to finalize the interface: the Operation class hierarchy and its fields, CLI, etc.
• Add type checking to CI and fix the existing issues
• Tortoise.generate_schemas and tortoise_pathway would generate different schemas, for instances, names of indexes and constraints might differ. We should either align them or officially decide that they won't match.
• Add documentation on how to migrate from aerich?

[channelcat]

Awesome 👍. I'm unfamiliar with Github's tooling but minimally it looks like we could set up a milestone and then attach issues to it.

Would you like me to create an issue for each one of these or would you prefer to?

[henadzit]

I would appreciate if you create issues!

[henadzit]

@channelcat, FYI, I just released 0.2.1 and softened the language in which I described the project and its code. You mentioned it multiple times, so I guess you care about it :) Maybe, it will help with finding new contributors.