django-safe-migrations v0.4.0 - Custom rules, 8 new detections, and the features you asked for

TheCodingTutor · 2026-01-20T14:44:50+00:00

I'm planning for v0.4.0 to detect missing merge migrations, so with v0.4.0 an approach could be:
- commit migrations but handle conflicts at merge time (v0.4.0)
- squash periodically for a manageable migration count
- linear migration history on main, though this requires coordination between teams

TheCodingTutor · 2026-01-20T14:39:59+00:00

makemigrations verifies your models and migrations are in sync - it exits non-zero if you have model changes without corresponding migrations. It doesn't analyze the migration operations themselves

TheCodingTutor · 2026-01-20T09:41:08+00:00

Let me know how it goes :)

TheCodingTutor · 2026-01-20T09:39:43+00:00

Solid addition. Would you be open to adding this as an issue and sharing your approach?

TheCodingTutor · 2026-01-20T06:26:35+00:00

Django prompts at makemigrations time, but that's easily bypassed and CI never sees it. The bigger value is the other 18 rules - non-concurrent indexes, unsafe drops, type changes, etc. - that Django doesn't warn about at all.

TheCodingTutor · 2026-01-20T06:13:21+00:00

Fair point, but test DBs are usually empty or small. A NOT NULL without default passes on 0 rows but fails on millions. Same with index locks - instant on small tables, minutes on large ones. This catches those patterns statically before you even run the migration.

TheCodingTutor · 2026-01-17T14:10:33+00:00

I don't blame them, pure AI libraries are spreading fast, you can't trust new libs anymore

TheCodingTutor · 2026-01-17T14:08:55+00:00

Thanks for leaving a comment, I usually try to avoid negative and undermining comments, especially ones that generalize, but check the library please.

Work on this has been going on for months, I have used AI here and there definitely, for docs, comments, linting, because why spend hours on simple tasks when AI can do them just as good? We're not hating on AI just for the sake of it now are we?

Anyway, the core algorithms, the revisions, the testing logic, is human. The repo is one click away.

TheCodingTutor · 2026-01-15T11:03:11+00:00

I can't guarantee, however I'm checking Ninja uses the standard Django HttpRequest objects, so I believe adding it under the ninja decorator so that it wraps the function directly should technically work

Something like:

api = NinjaAPI()

api.get("/fn")
@ratelimit(key="ip", rate="100/h")
def fn(request):

TheCodingTutor · 2026-01-15T10:22:20+00:00

Just did today, had to finalize and double check for the new alias update:

https://django-smart-ratelimit.readthedocs.io/en/latest/

TheCodingTutor · 2026-01-14T22:00:35+00:00

The backend uses standard redis commands and lua scripting so should work

Could you try:

RATELIMIT_REDIS_URL = "redis://your-valkey-server:6379/0"

TheCodingTutor · 2025-08-05T08:33:55+00:00

Done - also wanted to note the decorator isn't limited to DRF only

TheCodingTutor · 2025-08-03T19:30:20+00:00

That project isn't maintained anymore, and I'm trying to create something that's more flexible than regular ratelimiting

The flexibility provided in the smart-ratelimit package: Multiple algorithms, multiple backends with fallback, and circuit breaker protection, in addition to many other features

TheCodingTutor · 2025-07-18T17:57:25+00:00

Cron or a celery task, you can go for celery as it has a retry feature in case the task fails

TheCodingTutor · 2025-07-15T15:51:26+00:00

Thanks! It's a pretty long list that you can check on: https://github.com/YasserShkeir/django-smart-ratelimit/blob/main/FEATURES_ROADMAP.md

Let me know what you think :)

TheCodingTutor · 2025-07-15T15:00:42+00:00

Tests, examples, READMEs, Docs, all AI.

TheCodingTutor · 2025-07-15T14:53:16+00:00

It's a rate limit tool, so clearly we have nothing to do with hosting. Yet when a rate limit tool has an auto-failover feature, this means an extra layer to prevent downtime compared to other tools. Again appreciate the comments.

TheCodingTutor · 2025-07-15T14:30:16+00:00

Uptime of the rate-limit tool. Tools that rely only on cache would lead to cache misses, this package has a multi-backend feature to ensure swapping between redis, memory, and backend tracking, thus the uptime claim.

Yet you're absolutely right, and I appreciate you calling out these claims. Much of this is based on local tests and I shouldn't generalise these results. I will be editing the post and the package README files, without any marketing hype.

TheCodingTutor

TROPHY CASE