Add support for querying datetime fields

[abrookins]

This PR makes a few changes, all to support datetime fields better.

Store datetime fields as NUMERIC data in Redis

Previously, we stored datetimes as TAGs (why, I don't know). This means any query you might think would work with dates would not actually work. Now, we convert datetime fields on models to and from NUMERIC fields in Redis, storing them as UNIX timestamps. This means we can support rich datetime queries by converting the input to a timestamp and comparing it against the stored timestamp.

New data migrations system

Introduces a data migrations system and CLI command (om migrate-data). The first built-in data migration will migrate datetime fields indexed as TAG data to NUMERIC data. Important: You must run this migration in order to use this version of Redis OM with datetime fields, as the models will now expect to get NUMERIC data for datetimes fields.

New top-level om CLI command

Moves OM CLI commands into a new top-level om command while preserving backwards compatibility for the old migrate command. This makes room for normal migration and now data migration commands.

Expanded schema migrations system

To match the new om migrate-data sub-commands, such as run and create, we expand the schema migrations system to support these features through file-based migrations. This introduces the possibility to roll back migrations, as well as practical concerns like deploying migrations to different environments and checking whether or not they have applied.

[Copilot]

Pull Request Overview

This PR implements timestamp handling for datetime fields in Redis-OM Python by converting datetime objects to Unix timestamps for storage, enabling proper NUMERIC indexing in RediSearch. It includes a comprehensive data migration system and moves CLI commands under a unified om command structure.

• Convert datetime fields from string/object storage to Unix timestamp storage for proper indexing
• Add data migration framework with dependency management and rollback support
• Create unified om CLI interface while maintaining backward compatibility

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
tests/test_datetime_fix.py	Tests datetime timestamp conversion for HashModel and JsonModel
tests/test_datetime_date_fix.py	Tests date field conversion to timestamps
tests/test_data_migrations.py	Comprehensive test suite for the data migration system
pyproject.toml	Adds new om CLI entry point with backward compatibility
docs/migrations.md	Complete documentation for schema and data migration systems
aredis_om/util.py	Extends NUMERIC_TYPES to include datetime types
aredis_om/model/model.py	Core timestamp conversion logic and model save/get modifications
aredis_om/model/migrations/datetime_migration.py	Built-in migration to convert existing datetime data
aredis_om/model/migrations/data_migrator.py	Framework for managing data migrations
aredis_om/model/cli/migrate_data.py	CLI commands for data migration operations
aredis_om/cli/main.py	Unified CLI entry point
aredis_om/cli/init.py	CLI package initialization

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[abrookins]

This allows users to use normal type annotations for datetime fields, instead of a special field type we provide, even if it's messier "on the backend."

[bsbodden]

LGTM! 🦭🆗

[jeremyplichta]

I think TAGs are sortable, at least according to the docs

SORTABLE - NUMERIC, TAG, TEXT, or GEO attributes can have an optional SORTABLE argument. As the user sorts the results by the value of this attribute, the results are available with very low latency. Note that his adds memory overhead, so consider not declaring it on large text attributes. You can sort an attribute without the SORTABLE option, but the latency is not as good as with SORTABLE.

[abrookins]

Ah, nice, this is outdated then!

[abrookins]

We need to update the TAG field docs.