Refactor task model and params

[ellnix]

Minor refactoring to convert the TaskResults model to inherit from CamelBase. In addition, allows for tuples in addition to lists in several parameters.

DocumentResults and Document remain the only models that do not inherit from CamelBase. Since Document's attributes are dynamic, I don't know if that can be achieved.

[sanders41]

It should also work to do this in IndexStats with a model like

class IndexStats(CamelBase):
    number_of_documents: int
    is_indexing: bool
    field_distribution: dict[str, int]

DocumentResults and Document remain the only models that do not inherit from CamelBase. Since Document's attributes are dynamic, I don't know if that can be achieved.

This is good. The way I have handled this elsewhere is with generics, but that would be a big breaking change so better to leave it like you have it.

[ellnix]

It should also work to do this in IndexStats with a model like

class IndexStats(CamelBase):
    number_of_documents: int
    is_indexing: bool
    field_distribution: dict[str, int]

Done. It's a pretty big breaking change if you ask me, since field_distribution is now a dict rather than an object.

I ended up deleting a test file entirely since it seemed to just be a test of the metaprogramming behind the old IndexStats. Presumably that behavior is guaranteed by the tests on CamelCase.

[sanders41]

Done. It's a pretty big breaking change if you ask me, since field_distribution is now a dict rather than an object.

That is fair. What I think we could do is make the field_distribution type a FieldDistribution class that is dynamic like before and use a pre-validator to populate it. If you know how to do that and want to give it a try go for it, otherwise I'll test it out as soon as I get a chance to see if it works.

[ellnix]

That is fair. What I think we could do is make the field_distribution type a FieldDistribution class that is dynamic like before and use a pre-validator to populate it. If you know how to do that and want to give it a try go for it, otherwise I'll test it out as soon as I get a chance to see if it works.

I can give that a shot in a couple of hours. I've never done it before but I'll read documentation until I figure it out 😆

[sanders41]

I can give that a shot in a couple of hours. I've never done it before but I'll read documentation until I figure it out 😆

If you work on it, for now just focus on Pydantic 2. Since this will be a breaking change anyway I'm considering removing Pydantic 1 support also in this release. Pydantic 2 has been out for over a year and as far as I'm aware all the major libraries support it now so it shouldn't be an issue to remove support for v1.

[ellnix]

Did some reading, turned out to be pretty straightforward. I can make it pydantic 1 compatible too if you want.

[ellnix]

I made a test to see what happens if field_distribution was an int and without this line you get the mysterious:

FAILED tests/index/test_index_stats_meilisearch.py::test_make_trouble - TypeError: '
int' object is not iterable

versus the new

FAILED tests/index/test_index_stats_meilisearch.py::test_make_trouble - TypeError: "
field_distribution" in IndexStats must be a dict

[ellnix]

If I'm understanding the documentation correctly, this is necessary.

[ellnix]

I saw that there was an Annotated pattern and a functional pattern.

The functional pattern made more sense to me, it looked more descriptive and everything was gonna stay in class anyway.