Question on ordering of fields

[CaptainDriftwood]

Just wondering what it is I am doing incorrectly when wanting to order fields:

Per the documentation (https://wyfo.github.io/apischema/de_serialization/#class-level-ordering), this works as expected.

However, when I try to do the following:

@order(["hairColor", "name", "age"])
@dataclass
class Person:
    """Model to represent a person object"""

    name: str
    age: int
    hair_color: str = field(metadata=alias("hairColor"))

person = Person("John", 21, "Brown")
print(json.dumps(serialize(person)))
>>> '{"hairColor": "Brown"}'

What I would expect the output to be is as follows:

>>> '{"hairColor": "Brown", "name": "John", "age": 33}'

Am I doing something wrong? Also, when decorating the class with the order decorator, type hints get lost when instantiating the class object. Is there any way to fix that?

[wyfo]

There are several issue here: a misuse due to an incomplete documentation, a bug, and maybe a feature request.

On the one hand, about the documentation; apischema has several features expecting fields as argument, for example fields validator or ordering. This not really documented, but fields can be passed either as a dataclass field (convenient inside class body), apischema.objects.ObjectField or a string, which is expected to be the field name. Field alias cannot be used here, so your example will not work. You have to replace "hairColor" by "hair_color".

On the other hand, there is a bug in the current implementation (i will fix it today and release it in v0.16.1 at the same time). Ordering after and 'before are not resolved recursively, and applying order at class level is just a shortcut to chain after. In your example, it would give:

@dataclass
class Person:
    name: str = field(metadata=order(after="hair_color"))
    age: int = field(metadata=order(after="name"))
    hair_color: str = field(metadata=alias("hairColor"))

That's why, even if you fix your decorator to be @order(["hair_color", "name", "age"]), age field will still not be serialized. The correction is quite trivial, and as I've written above, it will be patched and available today.

I will also update the documentation to precise that field aliases cannot be used, for the moment. I understand that it could be convenient to use aliases in addition to field names, and I will think about it. I should not be so hard to do, even if there is some edge cases to handle, but I have other priority things to implement at this moment.

By the way, regarding your example, apischema provides dynamic/global aliasing, which is a lot more convenient than aliasing fields one by one, especially for camelCase handling.

P.S. Don't hesitate to create issue instead of question when the things looks a lot like a bug (having fields not serialized). I've created #227

[wyfo]

define aliasing behavior at the class level instead of global/per field level (via a decorator)?

Yes, take a look at the documentation

define aliasing for a specific serializer (i.e., using one serializer for one use case, and a different one for another)?

I'm not sure to understand what do you mean. If you want for example to serialize with camelCase for on one side, and with snake_case on the other side, you can use aliaser parameter of apischema.serialize/apischema.serialization_method.
Otherwise, if you mean having two different aliasing for the same class, depending on a given context, you could use object serialization in order to override the alias metadata of the fields you want.
(There are also equivalent mechanisms for deserialization)

Does it answer your question?

[CaptainDriftwood]

Yes, that does answer my question. Also, with the new order decorator, is there a way to have the order of the fields be alphabetical (in either ascending or descending order)? I'm not seeing a way to specify this behavior at the class decorator level in the documentation.

[wyfo]

is there a way to have the order of the fields be alphabetical

There is not, at least at simple one, and that could indeed be a good feature idea.
If you don't have any serialized methods, here is a way you can accomplish that with one (long) line of code:

import json
from dataclasses import dataclass

from apischema import serialize, serializer, type_name
from apischema.json_schema import serialization_schema
from apischema.objects import object_fields, object_serialization


@dataclass
class MyClass:
    foo: int
    bar: int


# Create a dynamic object serialization reusing all fields, but sorted;
myclass_sorted = object_serialization(
    MyClass,
    lambda: sorted(object_fields(MyClass).values(), key=lambda f: f.alias),
    type_name(None),  # in order to not have intermediate class added in JSON schema.
)
# Register a default serializer
serializer(myclass_sorted)

assert json.dumps(serialize(MyClass(0, 1))) == '{"bar": 1, "foo": 0}'
assert serialization_schema(MyClass, all_refs=True) == {
    "$ref": "#/$defs/MyClass",
    "$defs": {
        "MyClass": {
            "type": "object",
            "properties": {"bar": {"type": "integer"}, "foo": {"type": "integer"}},
            "required": ["bar", "foo"],
            "additionalProperties": False,
        }
    },
    "$schema": "http://json-schema.org/draft/2020-12/schema#",
}

[wyfo]

I've created #229 to continue the discussion about alphabetical ordering. Feel free to take a look at it.

[CaptainDriftwood]

Awesome, this is good stuff. Thank you for the assistance and the very prompt responsiveness. Out of my own curiosity, how would one implement this with serialized methods/properties (or is this not currently possible)?