Django

An object-relational mapper: you define tables as models.Model classes and query them in Python with .objects.filter(...) instead of raw SQL. It generates the SQL, manages migrations, and maps rows back to model instances.

It ships users, groups, permissions, and cookie sessions. AuthenticationMiddleware attaches request.user per request; authentication verifies identity by login/password with hashers, authorization checks permissions. OAuth is third-party.

A nested configuration class holding metadata about the outer class — like model, fields/exclude, ordering, and db table name — read by Django's metaclass when the class is built. It configures the class; it is not itself a field.

A pluggable hook that wraps every request and response. You enable it by adding its path to MIDDLEWARE; entries run top-down on the request and bottom-up on the response, and any one can inspect, modify, or short-circuit with its own reply.

Pull the shared amount_* fields and to_dict into an abstract base model — class AmountBase(models.Model): ... with class Meta: abstract = True — and have both models inherit it; abstract bases create no table, only inherited columns. The key correctness fix: money as FloatField is a bug (binary float rounding) — use DecimalField. Also reconsider the loose null=True on amount/currency fields.

CsrfViewMiddleware puts a random token in a cookie and makes unsafe methods (POST/PUT/DELETE) echo a matching csrfmiddlewaretoken in a form field or header; a mismatch returns 403. GET is exempt, and @csrf_exempt opts a view out.

As a separate join (bridge) table holding foreign keys to both sides plus any extra fields, since one column can't reference many rows. Queries JOIN through it, and Django auto-creates this table for a ManyToManyField.

select_related performs a SQL JOIN and pulls the related rows in one query — only for single-valued relations (ForeignKey, one-to-one). prefetch_related runs a separate query per relation and joins them in Python — it supports many-to-many and reverse ForeignKey. Both fix the N+1 query problem by loading related objects up front instead of per access.

It converts between model instances and primitive types like JSON: serializing data out for API responses, and validating then deserializing incoming data into instances. A ModelSerializer derives its fields from a model via its Meta.

A publish/subscribe mechanism: components emit signals like pre_save and post_save, and registered receivers react. Dispatch is SYNCHRONOUS — it runs inside the same request, so a slow receiver directly slows the response that fired it.

Django is batteries-included: a built-in ORM, admin, auth, templating, and project structure ship full sites fast. Flask is a microframework with a minimal core — you pick each component yourself, keeping it flexible for small services.

Annotate each row with its position in the list using Case/When, then order by that annotation: preserved = Case(*[When(id=pk, then=pos) for pos, pk in enumerate(ids)]), then MyModel.objects.filter(pk__in=ids).annotate(_order=preserved).order_by('_order'). The database evaluates the CASE expression per row, so the requested order is produced in SQL, not re-sorted in Python.

Safe methods (GET/HEAD/OPTIONS/TRACE) must be side-effect-free per HTTP, so a forged GET can't cause harm and is exempt. Over HTTPS Django also checks Referer/Origin against trusted hosts to block MITM cookie-injection.

Query both neighbours: the nearest row at or after the requested time (filter(datetime__gte=t).order_by('datetime').first()) and the nearest at or before it (filter(datetime__lte=t).order_by('-datetime').first()), then return whichever has the smaller absolute time delta. A naive one-sided .first() ignores the closer row on the other side. With an index on datetime, each bounded query is an index seek — efficient even on a large table.