⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.02%. Comparing base (e304a84) to head (206309f).
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@            Coverage Diff             @@
##           master    #7025      +/-   ##
==========================================
+ Coverage   50.99%   51.02%   +0.03%     
==========================================
  Files         455      455              
  Lines       56994    56997       +3     
  Branches     8321     8321              
==========================================
+ Hits        29063    29082      +19     
+ Misses      25946    25934      -12     
+ Partials     1985     1981       -4     

@ntkathole LMK if you have any thoughts on this PR.

The numeric filter correctness fix and the backward-compatible alias look reasonable. One migration concern: the documented feast teardown → feast apply → rematerialize sequence drops the existing collection before it is repopulated, so this can create a serving outage and potentially lose online-only state. Could we add an explicit destructive / downtime warning and recommend a backup or staged migration (e.g. a new collection with cutover) for production deployments? Also, the current tests establish the newly created native-typed collection, but could we add a regression that creates a VARCHAR collection first, flips native_numeric_types=True without teardown, then verifies reads/writes still work and numeric range filters continue to warn/use the existing storage semantics? This would pin down the promised mixed old/new collection behavior.

@haoxu0 thank you for the review, both points are addressed in 206309f.
Let me know if there's anything else - could a maintainer rerun the failed unit-test-python check?

Migration warning. The Numeric types section now has a warning hint: feast teardown drops the collections of every feature view in the project, online reads fail until materialization finishes, and rows that only exist in the online store (push sources, write_to_online_store) are lost. The section also documents a staged cutover that needs no teardown: add a copy of the feature view under a new name (which creates a new native-typed collection), materialize it, move readers to it, then remove the old view. It points to Milvus Backup for anyone who still wants to tear down.

Mixed-collection regression. test_native_numeric_types_keeps_existing_varchar_collection creates a VARCHAR collection, turns on native_numeric_types without a teardown, and checks that the collection stays VARCHAR and that writes and online_read still round-trip.

Writing that test showed that the existing warning (and my docs) described the wrong behaviour on VARCHAR collections. A numeric filter value doesn't compare lexicographically: Milvus rejects it (comparisons between VarChar and Int64 are not supported on Milvus 3.0.2, with a similar error on Lite). Only a string value like "50" compares as text. The test now pins both cases and the warning, and I've corrected the warning text and docs to match. I left the filter behaviour itself unchanged: an error is safer than silently wrong results.