Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ContextEntity more Customizable #225

Closed
tstorek opened this issue Dec 28, 2023 · 3 comments · Fixed by #256
Closed

Make ContextEntity more Customizable #225

tstorek opened this issue Dec 28, 2023 · 3 comments · Fixed by #256
Assignees
Labels
feature request Request a potential feature

Comments

@tstorek
Copy link
Collaborator

tstorek commented Dec 28, 2023

Is your feature request related to a problem? Please describe.
Currently, subsclassing of ContextEntity is rather difficult because the Model tends to overwrite customized subslasses of ContextAtrributes with ContextAttribute-Type. This acutally should only happen if a user does not know the customized subclasses.
However, if one want's to implement a RestAPI with more specific types you usually need to subclass and define stricter models as the generic ones.
Furthermore, schema-export only returns unspecific schemas. That is not what you want when providing a service.

Describe the solution you'd like

  1. Prohibit overwriting customized ContextAttributes by checking the defined FieldTypes
  2. Add example of how to properly inherit ContextEntity and specify custom ContextAttribute-types for proper schema generation.

Describe alternatives you've considered
Write your own intermediate class that allows for the functionality described above.

Example*

from pprint import pprint
from pydantic.fields import FieldInfo


class WeatherStation(ContextEntity):
    """
    A dedicated weather station.
    https://brickschema.org/schema/Brick#Weather_Station
    """
    id: str = FieldInfo.merge_field_infos(
        ContextEntity.model_fields["id"],
        title="ID of the Weather Station",
        frozen=False,
        examples=["ngsi-ld:WeatherStation:001"],
        description="ID of the Weather Station. Allowed characters are the "
                    "ones in the plain ASCII set, except the following ones: "
                    "control characters, whitespace, &, ?, / and #."
    )

    type: str = FieldInfo.merge_field_infos(
        ContextEntity.model_fields["type"],
        title="Type of the Weather Station",
        default="brick:Weather_Station",
        validate_default=True,
        frozen=False,
        examples=["brick:Weather_Station"],
        description="Type of the Weather Station. You can leave it to the "
                    "default value if you are using the Brick models. Allowed "
                    "characters are the ones in the plain ASCII set, except "
                    "the following ones: control characters, whitespace, &, "
                    "?, / and #."
    )

pprint(WeatherStation.model_schema_json())
@tstorek tstorek added the feature request Request a potential feature label Dec 28, 2023
@tstorek tstorek self-assigned this Dec 28, 2023
Copy link

Branch 225-Make-ContextEntity-more-Customizable created!

@tstorek tstorek added this to the inheritance of ContextEntity milestone Dec 29, 2023
@tstorek
Copy link
Collaborator Author

tstorek commented Dec 29, 2023

@djs0109 This will also require to use the former fiware regex patter. Within in the pattern field of pydantic.field. Meaning that we will set the regex_engine to python for ContextEntity. The current implementation prohibits the documentation of the regex via json_schema export

tstorek added a commit that referenced this issue Mar 5, 2024
tstorek added a commit that referenced this issue Mar 5, 2024
tstorek added a commit that referenced this issue Mar 6, 2024
tstorek added a commit that referenced this issue Mar 6, 2024
tstorek added a commit that referenced this issue Mar 6, 2024
tstorek added a commit that referenced this issue Mar 6, 2024
tstorek added a commit that referenced this issue Mar 6, 2024
tstorek added a commit that referenced this issue Mar 7, 2024
tstorek added a commit that referenced this issue Mar 7, 2024
tstorek added a commit that referenced this issue Mar 7, 2024
tstorek added a commit that referenced this issue Mar 12, 2024
tstorek added a commit that referenced this issue Mar 12, 2024
tstorek added a commit that referenced this issue Mar 12, 2024
tstorek added a commit that referenced this issue Mar 18, 2024
tstorek added a commit that referenced this issue Mar 18, 2024
@tstorek
Copy link
Collaborator Author

tstorek commented Mar 18, 2024

@djs0109 Hej, if everything is fine now, we will be able to merge, right? I would need this one and the #258 quite urgently.

tstorek added a commit that referenced this issue Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Request a potential feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant