GetterDict / Pydantic v2

[SmileyChris]

(Following on from discussion in #396 )

A root_validator(pre=True) decorated on the the Schema base class can do everything _convert_result does.

If you wanted, a basic version of resolvers might work there too: use the validator classmethod to just look for resolve_[x] methods directly. This, combined with my understanding of how validation context works means we could pass the original object as context and pass this on to the resolver objects, yeah? It's fancy what we're doing with self on resolvers, but I don't know if it's that necessary to reimplement that initially (it's easy just having them as staticmethods that receive the obj).

Also, with v2's aliased paths, I don't really think we need any magic dotted alias, since this comes out of the box now.

[vitalik]

@SmileyChris yeah, root_validator(pre=True) might actually work - I never noticed that it goes inside iterated objects as well

Also, with v2's aliased paths, I don't really think we need any magic dotted alias, since this comes out of the box now.

Well Ideally i would keep doted aliases as there are some companies/projects use it alot - and it would be nice if they migrate to pydantic2 without any codebase change (maybe even both aliased-paths and doted can work together) / or with some slow deprecation procedure...

[SmileyChris]

Oh, the other cool thing I was thinking about this morning would be to add request as part of the validation context that could get passed to resolvers that want it, making us able to do things like filtering based on user at the schema level.

[baseplate-admin]

the other cool thing I was thinking about this morning would be to add request as part of the validation context that could get passed to resolvers that want it, making us able to do things like filtering based on user at the schema level.

Also we can build HyperLinked URL's this way.

---

Some thoughts on this:

• It would be better if we pass request as a parameter instead of class variable ( because i am generally against using abstract class variables )

def validate_user(self, request:HttpRequest, instance:UserModel) -> str:
   return instance.username

[SmileyChris]

It would be better if we pass request as a parameter

Yes, I was assuming that request would be an optional parameter. In fact, I kinda like the idea behind all the parameters needing to be typed, and it would fill in the parameters based on the matching types found in the validation context.

class Room(Schema):
    title: str
    user_count: int
    recent_threads: list[Thread]

    @staticmethod
    def resolve_user_count(room: models.Room) -> int:
        return room.users.count()

    @staticmethod
    def resolve_recent_threads(room: models.Room, request: HttpRequest) -> str:
        return room.thread_set.filter(threads=request.user)[:10]

[baseplate-admin]

Yes, I was assuming that request would be an optional parameter. In fact, I kinda like the idea behind all the parameters needing to be typed, and it would fill in the parameters based on the matching types found in the validation context.

Hey this is a really good proposition. I am with you on this one

def resolve_recent_threads(room: models.Room, request: HttpRequest) -> str:
        return room.thread_set.filter(threads=request.user)[:10]

Not a big fan of passing request as second argument as django's doc recommends request to be the first parameter.

[SmileyChris]

This isn't a view, but I get you on that. It wouldn't matter about the order if it was based on type. The reason it's second in this example was to show that it was indeed optional (whereas it nearly always makes sense that you'd be passing the original object)