Roadmap

• JSON fields
• More aggregation functions - e.g. SUM
• Aliases in SELECT queries (e.g. SELECT foo AS bar FROM my_table)
• Improved support for data migrations
• Fixtures
• Schema visualisation tool
• piccolo sql_shell new command - execute SQL directly in a shell, via the configured engine
• piccolo shell new command - like the playground, but for your own tables
• Shorter aliases for commands in CLI, or tab completion
• Improved documentation for how to test Piccolo apps
• Nested transactions
• Move Pydantic integration from Piccolo API into Piccolo
• Allow the ForeignKey references argument to accept a string such as 'my_app.SomeTable' when circular imports are an issue.
• Support Postgres Enum types.
• Row level constraints.
• Making foreign key constraints optional on ForeignKey columns.
• Allow UUIDs as primary keys?
• Subqueries

[dantownsend]

@heliumbrain Some great suggestions there, thanks. I’ve created a separate discussion thread to explore these ideas more.

[heliumbrain]

Hi! I’ve spent enough time with Piccolo the last week or so to get a decent grasp of it. Would like to give my feedback, even though all of it can’t directly be translated to roadmap items.

First of all, I think it would make sense to split the roadmap in to 3 main areas, depending on what you envision for Piccolo in the next year or so.

Providing a modern (ASGI) ORM

This would include the features that users might be expecting from a ORM but is not in Piccolo right now for one reason or another, such as:

1. Support for M2M fields
2. Improvements to migration
3. Improved documentation with onboarding for users with different backgrounds (coming from Django, SQLAlchemy or something comepletely different)

Supporting the wider ASGI ecosystem

I think this is a potentially huge area. Looking at the ASGI ORM landscape there’s a big need for a complete solution (a lá Django + Django ORM). There’s great async ORMs out there, and the tooling around them (auth, admin, etc.) definitely exists - but there’s not a single complete package available with as little pain points as Piccolo. I also think that with the migration to SQLAlchemy 1.4 and down the line 2.0, a lot of ORMs will struggle. Not being reliant on SQLAlchemy can be a great thing in this circumstance 😃 This area would include stuff as:

1. Support for dependency injection in FastAPI
2. Clearer (or less) separation between Piccolo and Piccolo-API
3. Provide components (such as login, admin) that’s easy to get started with - but also provide a clear way to tweak it and “plug it in” to other frameworks (Starlette, FastAPI, Blacksheep, …)
   1. The current admin and session-auth is probably the best I’ve seen for FastAPI. But there’s other solutions out there that’s much easier to get up and running with
4. Docs, docs, docs & examples 😃
5. Move Pydantic integration from Piccolo API into Piccolo

Making Piccolo the best it can be

This area would include anything else that doesn’t fit in to the other two. Stuff that will really make Piccolo stand out (if that’s what you want) or just in general be a great ORM

Here I think there’s a decision to be made. Do you want Piccolo to be the best all-purpose Python ASGI ORM that CAN tie in to frameworks such as FastAPI - Or do you want Piccolo to be THE BEST FastAPI/Blacksheep/Starlette ORM that can also fill other purposes. I might be wrong, but I think it will be hard to fill both those roles.

This ended up being longer than expected, but just wanted to give you my thought after a few days of using Piccolo. Big kudos @dantownsend - you’ve done a fantastic job! Happy to help out where I can moving forward 🚀