Use model_validate built into pydantic to parse DB models

[b-rowan]

pydantic models have a deprecated from_orm method, which is designed to parse DB models into the schema. This was superseded by model_validate, which does the same thing when the schema config from_attributes value is true. Migrating to using this simplifies the method of parsing DB models, and will eventually allow the schemas to be used internally instead of the DB models.

Reference here - https://docs.pydantic.dev/2.0/usage/models/#arbitrary-class-instances

The goal here is to get to the point where we can pass around arbitrary abstract software types internally, which will allow hooking the software that a device should receive.

[tsagadar]

Took my third attempt to wrap my head around this PR - with limited success. I think there are three things in this PR

1. Simplify the Pydantic model instantiation relying on from_attributes. As an independent commit I think it would be an obvious valuable refactoring.
2. Move logic from the DB models (entities) to the schema (DTO). Not really sure if this is a good idea. Usually logic would remain in the entities.
3. Preparation work for implementing the "initial update for device without unique identifier" use case through a plugin mechanism. It could help to describe this as a feature request - even if the idea is to implement it as a plug-in. This could allow to understand how this can fit into gooseBit. Maybe the feature should even be part of the regular code base and that can be activated through a configuration?

[b-rowan]

3. Preparation work for implementing the "initial update for device without unique identifier" use case through a plugin mechanism. It could help to describe this as a feature request - even if the idea is to implement it as a plug-in. This could allow to understand how this can fit into gooseBit. Maybe the feature should even be part of the regular code base and that can be activated through a configuration?

It's not specifically that, I actually had a cloudflare integration in mind. Right now with our internal version (which is very outdated), we have a cloudflare integration which creates tunnels to devices automatically based on UUIDs. This requires configuring cloudflared on the device with a specific private key, and in order to do that we are generating a custom SWU that only writes to that config file, then pushing it to the device. So the idea would be to check for gooseBit updates for a device, then check for custom SWU file from plugin, and to do that we need a standard internal interface that doesn't require creating a DB entry (as I would like to delete these SWU's off disk ASAP, we can always regenerate them later).

[b-rowan]

Simplify the Pydantic model instantiation relying on from_attributes. As an independent commit I think it would be an obvious valuable refactoring.

I think you're right about this for now. I have made this PR a bit more atomic by removing 2 and 3. I would really like to be able to get a plugin interface of some kind included here, I want to have our internal stuff up to date, but it seems every foothold I've tried to gain on that side of things causes one issue or another. If you have any ideas on that side of things LMK.

[tsagadar]

Looks good. Just minor issues that are optional to address in my opinion.

[tsagadar]

Simplify the Pydantic model instantiation relying on from_attributes. As an independent commit I think it would be an obvious valuable refactoring.

I think you're right about this for now. I have made this PR a bit more atomic by removing 2 and 3. I would really like to be able to get a plugin interface of some kind included here, I want to have our internal stuff up to date, but it seems every foothold I've tried to gain on that side of things causes one issue or another. If you have any ideas on that side of things LMK.

@b-rowan let's discuss this through another channel. Can you send me an email to the address from my commits?

[b-rowan]

Can you send me an email to the address from my commits?

Done. Sent from my upstreamdata.ca email.

[easybe]

@b-rowan why are these lines needed?

[b-rowan]

Not really sure why I've been adding them, just a good failsafe. Need to modify my IDE settings to stop complaining about them I think.