cadwyn 5.4.1__tar.gz → 5.4.2__tar.gz

{cadwyn-5.4.1 → cadwyn-5.4.2}/CHANGELOG.md

@@ -5,6 +5,12 @@ Please follow [the Keep a Changelog standard](https://keepachangelog.com/en/1.0.
 
 ## [Unreleased]
 
+## [5.4.2]
+
+### Fixed
+
+* Added support for computed fields
+
 ## [5.4.1]
 
 ### Fixed

{cadwyn-5.4.1 → cadwyn-5.4.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cadwyn
-Version: 5.4.1
+Version: 5.4.2
 Summary: Production-ready community-driven modern Stripe-like API versioning in FastAPI
 Project-URL: Source code, https://github.com/zmievsa/cadwyn
 Project-URL: Documentation, https://docs.cadwyn.dev

{cadwyn-5.4.1 → cadwyn-5.4.2}/cadwyn/schema_generation.py

@@ -236,6 +236,11 @@ def _wrap_validator(func: Callable, is_pydantic_v1_style_validator: Any, decorat
         func = func.__func__
     kwargs = dataclasses.asdict(decorator_info)
     decorator_fields = kwargs.pop("fields", None)
+
+    # wrapped_property is not accepted by computed_field()
+    if isinstance(decorator_info, ComputedFieldInfo):
+        kwargs.pop("wrapped_property", None)
+
     actual_decorator = PYDANTIC_DECORATOR_TYPE_TO_DECORATOR_MAP[type(decorator_info)]
     if is_pydantic_v1_style_validator:
         # There's an inconsistency in their interfaces so we gotta resort to this
@@ -1061,19 +1066,30 @@ def _delete_field_attributes(
 
 
 def _delete_field_from_model(model: _PydanticModelWrapper, field_name: str, version_change_name: str):
-    if field_name not in model.fields:
+    if field_name in model.fields:
+        model.fields.pop(field_name)
+        model.annotations.pop(field_name)
+        for validator_name, validator in model.validators.copy().items():
+            if isinstance(validator, _PerFieldValidatorWrapper) and field_name in validator.fields:
+                validator.fields.remove(field_name)
+                # TODO: This behavior doesn't feel natural
+                if not validator.fields:
+                    model.validators[validator_name].is_deleted = True
+
+    elif (
+        field_name in model.validators
+        and isinstance(model.validators[field_name], _ValidatorWrapper)
+        and hasattr(model.validators[field_name], "decorator")
+        and model.validators[field_name].decorator == pydantic.computed_field
+    ):
+        validator = model.validators[field_name]
+        model.validators[field_name].is_deleted = True
+        model.annotations.pop(field_name, None)
+    else:
         raise InvalidGenerationInstructionError(
             f'You tried to delete a field "{field_name}" from "{model.name}" '
             f'in "{version_change_name}" but it doesn\'t have such a field.',
         )
-    model.fields.pop(field_name)
-    model.annotations.pop(field_name)
-    for validator_name, validator in model.validators.copy().items():
-        if isinstance(validator, _PerFieldValidatorWrapper) and field_name in validator.fields:
-            validator.fields.remove(field_name)
-            # TODO: This behavior doesn't feel natural
-            if not validator.fields:
-                model.validators[validator_name].is_deleted = True
 
 
 class _DummyEnum(Enum):

{cadwyn-5.4.1 → cadwyn-5.4.2}/docs/home/CONTRIBUTING.md

@@ -66,7 +66,7 @@ Then you can serve the documentation with `mkdocs serve`
 
 We welcome contributions that enhance / improve the content of the docs. Feel free to add examples, clarify text, restructure the docs, etc., but make sure to follow these guidelines:
 
-* Write text in idiomatic english, using simple language
+* Write text in idiomatic English, using simple language
 * Opt for [Oxford commas](https://en.wikipedia.org/wiki/Serial_comma) when listing a series of terms
 * Keep examples simple and self contained
 * Provide links where applicable

{cadwyn-5.4.1 → cadwyn-5.4.2}/docs/index.md

@@ -12,7 +12,7 @@ Production-ready community-driven modern [Stripe-like](https://stripe.com/blog/a
     <img src="https://img.shields.io/codecov/c/github/zmievsa/cadwyn?color=%2334D058&logo=codecov" alt="Coverage">
 </a>
 <a href="https://pypi.org/project/cadwyn/" target="_blank">
-    <img alt="PyPI" src="https://img.shields.io/pypi/v/cadwyn?color=%2334D058&logo=pypi&label=PyPI package" alt="Package version">
+    <img alt="PyPI" src="https://img.shields.io/pypi/v/cadwyn?color=%2334D058&logo=pypi&label=PyPI" alt="Package version">
 </a>
 <a href="https://pypi.org/project/cadwyn/" target="_blank">
     <img src="https://img.shields.io/pypi/pyversions/cadwyn?color=%2334D058&logo=python" alt="Supported Python versions">
@@ -24,12 +24,12 @@ Production-ready community-driven modern [Stripe-like](https://stripe.com/blog/a
 
 ## Who is this for?
 
-Cadwyn allows you to support a single version of your code while auto-generating the schemas and routes for older versions. You keep API versioning encapsulated in small and independent "version change" modules while your business logic stays simple and knows nothing about versioning.
+Cadwyn allows you to maintain the implementation just for your newest API version and get all the older versions generated automatically. You keep API backward compatibility encapsulated in small and independent "version change" modules while your business logic stays simple and knows nothing about versioning.
 
-Its [approach](https://docs.cadwyn.dev/theory/how_we_got_here/#ii-migration-based-response-building) will be useful if you want to:
+This [approach](https://docs.cadwyn.dev/theory/how_we_got_here/#ii-migration-based-response-building) may be useful if you want to:
 
 1. Support many API versions for a long time
-2. Effortlessly backport features and bugfixes to older API versions
+2. Have features and bugfixes automatically backported to older API versions
 
 Whether you are a newbie in API versioning, a pro looking for a sophisticated tool, an experimenter looking to build a similar framework, or even someone who just wants to learn about all approaches to API versioning -- Cadwyn has the functionality, theory, and documentation to cover all the mentioned use cases.
 

cadwyn-5.4.2/docs/theory/how_to_build_versioning_framework.md

@@ -0,0 +1,24 @@
+# How to build a versioning framework
+
+## Questions to ask yourself when rating your framework
+
+### How easy is it to create a version?
+
+If it is too easy, it is probably a trap. The framework is probably hiding too much complexity from you and will shoot you in the back later. For example, early on we tried a simple "copy the entire business logic into a separate directory" approach which made it so simple to add new versions. We added too many of them in the end, thus it got hellishly hard to maintain or get rid of these versions.
+
+### How easy is it to delete an old version?
+
+Your framework must be able to let you clean up versions as simply as possible and cheaply whenever you need to. For example, if your framework tries to minimize the amount of code duplication in your repository by having new routes include old routes within them and new business logic inherit from classes from old business logic, then deleting an old version is going to be painful; oftentimes even dangerous as versions can quickly start interacting with each other in all sorts of ways, turning a single small application into a set of interconnected applications.
+
+### How easy is it to see the differences between versions?
+
+The easier it is, the better off our users are.
+
+### What exactly do you need to duplicate to create a new version?
+
+The less we duplicate and maintain by hand, the easier it is to support. However, the less we duplicate, the more chance there is to break the old versions with new releases.
+
+### How easy is it to notice accidental data versioning?
+
+Data versioning is an incredibly big issue when versioning your API.
+So if your framework makes it hard to version data -- it's really good!

{cadwyn-5.4.1 → cadwyn-5.4.2}/docs/theory/literature.md

@@ -1,6 +1,6 @@
 # Literature
 
-During Cadwyn's development, I went through countless resources on API Versioning. The following are the most unique and effective ones I could find.
+During Cadwyn's development, I went through countless resources on API Versioning. The following are the most unique and effective ones I managed to find.
 
 ## Cadwyn-like API Versioning
 

{cadwyn-5.4.1 → cadwyn-5.4.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "cadwyn"
-version = "5.4.1"
+version = "5.4.2"
 description = "Production-ready community-driven modern Stripe-like API versioning in FastAPI"
 authors = [{ name = "Stanislav Zmiev", email = "zmievsa@gmail.com" }]
 license = "MIT"

{cadwyn-5.4.1 → cadwyn-5.4.2}/tests/test_schema_generation/test_schema_field.py

@@ -3,7 +3,7 @@ from enum import Enum, auto
 from typing import Annotated, Any, Literal, Union
 
 import pytest
-from pydantic import BaseModel, Field, StringConstraints, ValidationError, conint, constr
+from pydantic import BaseModel, Field, StringConstraints, ValidationError, computed_field, conint, constr
 from pydantic.fields import FieldInfo
 
 from cadwyn.exceptions import (
@@ -762,3 +762,48 @@ def test__schema_field_had__nonexistent_field__should_raise_error(create_runtime
         ),
     ):
         create_runtime_schemas(version_change(schema(SchemaWithOneStrField).field("boo").had(type=int)))
+
+
+def test__schema_with_computed_field__should_be_recreated_in_older_version(
+    create_runtime_schemas: CreateRuntimeSchemas,
+):
+    class SchemaWithComputedField(BaseModel):
+        image_file_key: str = Field(exclude=True)
+
+        @computed_field
+        @property
+        def image_url(self) -> str:
+            return f"https://example.com/{self.image_file_key}"
+
+    schemas = create_runtime_schemas(version_change())
+
+    latest_model = schemas["2001-01-01"][SchemaWithComputedField]
+    old_model = schemas["2000-01-01"][SchemaWithComputedField]
+
+    latest_instance = latest_model(image_file_key="test.jpg")
+    old_instance = old_model(image_file_key="test.jpg")
+
+    assert latest_instance.image_url == "https://example.com/test.jpg"
+    assert old_instance.image_url == "https://example.com/test.jpg"
+
+
+def test__schema_with_computed_field__remove_computed_field(create_runtime_schemas: CreateRuntimeSchemas):
+    class SchemaWithComputedField(BaseModel):
+        image_file_key: str = Field(exclude=True)
+
+        @computed_field
+        @property
+        def image_url(self) -> str:
+            return f"https://example.com/{self.image_file_key}"
+
+    schemas = create_runtime_schemas(version_change(schema(SchemaWithComputedField).field("image_url").didnt_exist))
+
+    latest_model = schemas["2001-01-01"][SchemaWithComputedField]
+    latest_instance = latest_model(image_file_key="test.jpg")
+    assert latest_instance.image_url == "https://example.com/test.jpg"
+
+    old_model = schemas["2000-01-01"][SchemaWithComputedField]
+    old_instance = old_model(image_file_key="test.jpg")
+
+    assert not hasattr(old_instance, "image_url")
+    assert "image_url" not in old_instance.model_dump()

{cadwyn-5.4.1 → cadwyn-5.4.2}/uv.lock

@@ -98,7 +98,7 @@ wheels = [
 
 [[package]]
 name = "cadwyn"
-version = "5.4.1"
+version = "5.4.2"
 source = { editable = "." }
 dependencies = [
     { name = "backports-strenum", marker = "python_full_version < '3.11'" },

cadwyn-5.4.1/docs/theory/how_to_build_versioning_framework.md

@@ -1,23 +0,0 @@
-# How to build a versioning framework
-
-## Questions to ask yourself when rating your framework
-
-### How easy it is to create a version?
-
-If it is too easy: it is probably a trap. The framework is probably hiding too much complexity from you and will shoot you in the back later. For example, early on we have tried a simple "copy entire business logic into a separate directory" approach which made it so simple to add new versions that we added too many of them -- at the end, maintaining and getting rid of these versions has gotten hellishly hard.
-
-### How easy is it to delete an old version?
-
-Your framework must make it as simple as possible to make sure that you can clean up versions cheaply whenever you need to. For example, if your framework tries to minimize the amount of code duplication in your repository by having new routes include old routes within them and new business logic inherit from classes from old business logic, then deleting an old version is going to be painful; oftentimes even dangerous as versions can quickly start interacting with each other in all sorts of ways, turning a single small application into a set of interconnected applications.
-
-### How easy is it to see the differences between versions?
-
-The easier it is -- the better off our users are.
-
-### What exactly do you need to duplicate to create a new version?
-
-The less we duplicate and maintain by hand -- the easier it is to support. However, the less we duplicate -- the more chance there is to break the old versions with new releases.
-
-### How easy is it to notice accidental data versioning?
-
-Data versioning is an incredibly big problem when versioning your API so if your framework makes it hard to version data -- it's really good!