This feature adds native support for the Oracle Database’s ​Vector data type introduced in Oracle 23c. It enables AI and ML applications to store and query high-dimensional data directly in the database using a new VectorField model field, VectorIndex support for similarity search, and ORM expressions for vector operations.

Features Included:

VectorField model field:

1. Accepts optional dimensions, storage_format, and storage_type arguments.

2. Supports Dense and Sparse vector storage.

3. Auto-converts lists, NumPy arrays, and oracledb.SparseVector for insert/update.

Vector Index support:

1. VectorIndex class using Meta.indexes.

2. Support for HNSW and IVF index types.

3. Optional parameters: distance, accuracy, parallel, etc.

Vector distance expressions and lookups:

1. Custom Func class VectorDistance for VECTOR_DISTANCE(lhs, rhs, metric)

2. CosineDistance, EuclideanDistance, and NegativeDotProduct etc. as lookups.

3. Query syntax via filter() and order_by() for similarity search.

Testing:

1. Dense and Sparse vector insert/query tests added.

2. Stress test scripts for repeated inserts/queries included.

Example:

from django.db import models
VectorIndex = model.VectorIndex
VectorDistanceType = models.VectorDistanceType
VectorIndexType = models.VectorIndexType
class Product(models.Model):
    name = models.CharField(max_length=100)
    embedding = models.VectorField(dim=3, storage_format=VectorStorageFormat.FLOAT32, storage_type=VectorStorageType.DENSE)
    class Meta:
        indexes = [
            VectorIndex(
                fields=["embedding"],
                name="vec_idx_product",
                index_type=VectorIndexType.HNSW,
                distance=VectorDistanceType.COSINE,
            )
        ]

And a Similarity search can be performed

query_vector = array.array("f", [1.0, 2.0, 3.0])
    products = Product.objects.annotate(
        score=VectorDistance(
            "embedding",
            query_vector,
            metric=VectorDistanceType.COSINE,
        )
    ).order_by("score")[:5]

Implementation Status

We have already implemented:

1. Custom VectorField with support for DENSE and SPARSE formats

2. Automatic SQL generation for model/table creation

3. VectorIndex support with customizable parameters and distance metrics

4. ORM expressions and lookups for vector distance queries (e.g., CosineDistance, EuclideanDistance)

5. Basic tests for dense vector creation, insertion, indexing, and querying

6. Integration with Oracle’s Python driver (oracledb) for runtime behavior

PR Readiness

We have finalized the major components of this feature and are ready to open a public pull request after community feedback or approval of this feature proposal.

Hi,

I'm a Fedora packager that co-maintains our Django packages. When building 5.2.4 in Rawhide (the upcoming Fedora 43 release) that currently has Python 3.14b4, in addition to strip_tags() that our openSUSE colleague has reported (https://code.djangoproject.com/ticket/36499), test_parsing_errors also fails:

======================================================================
FAIL: test_parsing_errors (test_utils.tests.HTMLEqualTests.test_parsing_errors)
----------------------------------------------------------------------
AssertionError: &lt; div&gt; != <div>
- &lt; div&gt;   
+ <div>   

I'm currently conditionally disabling the test when building with Python >= 3.14, but hopefully this can be fixed.

When Django rejects a request because the Host header doesn't match ALLOWED_HOSTS, the resulting error message shows only the incoming header value:

Invalid HTTP_HOST header: 'localhost:8000'. You may need to add 'localhost' to ALLOWED_HOSTS.

This makes it harder to determine whether the problem is a misconfigured proxy (not setting the correct Host) or simply a missing hostname in ALLOWED_HOSTS. In many cases, the advice to "add localhost" is actively unhelpful: production deployments rarely serve requests at localhost, and the real fix is usually to configure the proxy correctly.

I’ve implemented a more helpful version of this logic in Bugsink (a Django app installed by users who may not be Django developers). I describe that implementation in more detail in [this blog post about improving Django’s ALLOWED_HOSTS error messages](​https://www.bugsink.com/blog/better-allowed-hosts/#better-error-messages). In the "bugsink approach" the error:

• shows the actual Host header and the configured ALLOWED_HOSTS
• suggests the likely cause
• avoids pointing users towards "add localhost" as the default fix

Some of what I did in Bugsink likely goes beyond what Django should adopt by default (e.g. showing the error in the browser), but the idea of displaying both values (the incoming host and the configured list) would be a broadly useful change on its own.

If desired, the message could also give more specific advice depending on the values (e.g. distinguish between loopback and public domains), but that can be considered separately.

Security considerations

Showing both the incoming Host header and the configured ALLOWED_HOSTS reveals limited information:

• The Host header is attacker-controlled — the client already knows what they sent.
• _or_ The Host header is simply a misconfiguration (in which case it's on-broken-deploy only)
• ALLOWED_HOSTS reveals the expected hostname(s). In most deployments, this is already visible in the TLS certificate.