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

Add dict->str and str->dict situations to recipes #84

Open
zmievsa opened this issue Nov 30, 2023 · 3 comments
Open

Add dict->str and str->dict situations to recipes #84

zmievsa opened this issue Nov 30, 2023 · 3 comments
Labels
documentation Improvements or additions to documentation high priority

Comments

@zmievsa
Copy link
Owner

zmievsa commented Nov 30, 2023

Let's say we have two versions: v1 and v2
Let's say that our response has a field "address: str" and we want to turn it into a dict in v2. How do we handle this situation in Cadwyn?
What about its reverse? (dict to str)

@zmievsa zmievsa added enhancement New feature or request high priority documentation Improvements or additions to documentation and removed enhancement New feature or request labels Nov 30, 2023
@zmievsa
Copy link
Owner Author

zmievsa commented Dec 22, 2023

This is essentially one of the most complex non-narrowing type change examples possible so it would fit really well in our docs.

@s-bose7
Copy link

s-bose7 commented Jan 8, 2024

Hello @zmievsa , been looking at the issue, can we approach this with the JSON library in Python? json.loads() could be used to convert a str to dict, and json.dumps() could be used to do the vice versa.

@zmievsa
Copy link
Owner Author

zmievsa commented Jan 8, 2024

@s-bose7 The problem is not in converting to a certain data type. The problem is converting to a certain format:

You see: Imagine that you stored addresses in your database like this in version 1:

150 Royall St., Suite 101\nCanton, MA 02021\nUnited States of America

Which could have all sorts of formatting issues and problems such as some addresses not including the last line or doing lines in a wrong order.

Let's say that we decided to set a strict format in version 2:

from pydantic import BaseModel

class Address(BaseModel):
    line1: str
    line2: str | None
    city: str
    country: str

That's great. But now we need to figure out how to make sure that v1 still works as it worked. There are a few ways to do this:

  1. A deprecation warning and deletion of all addresses that cannot be parsed
  2. Using a different field in database and in schemas for the new address style + make the new style optional in responses
  3. etc

Either way, it's a pretty tough task. It requires a great understanding of both API Versioning and Cadwyn. I recommend picking some of the tasks marked as good first issue instead :)

But if you would like to help with this one -- I am ready to review and help with any contributions 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation high priority
Projects
None yet
Development

No branches or pull requests

2 participants