16:57 <FromGitter> <Blacksmoke16> SamantazFox: I think we talked about this before, but would it be better to use `JSON::Serializable` such that the deserialization would straight up fail, which would be a clearer error indication?

16:58 <FromGitter> <Blacksmoke16> then you could have another type that your code uses in a format you like, then will just have to handle mapping the `JSON::Serializable` type to your internal type

17:02 <SamantazFox> Blacksmoke16: I see two problems with this solution

17:02 <SamantazFox> 1) We want to have as few errors as possible for the end user, so if some data is missing, we prefer to have a slightly broken experience rather than an error message

17:04 <SamantazFox> 2) the data structure is very complex (sometimes with many layers of arrays and objects) so we'd have to create tons of classes for the various possibilities. In addition to that, some fields depend on others, so parsing has to be done in a determined order...

17:05 <FromGitter> <Blacksmoke16> thats fair, could still use an internal type, but just build it out via `JSON.parse`

17:05 <FromGitter> <Blacksmoke16> if you're not already doing that

17:06 <SamantazFox> `JSON.parse` with a block?

17:09 <FromGitter> <Blacksmoke16> no i mean like instead of doing `parse response => pass `JSON::Any` around to use it in code` do like `parse response => use the `JSON::Any` type to build out some internal type that has all the data you need => pass internal type around to use it in code`

17:10 <FromGitter> <Blacksmoke16> such that if/when the data structures changes, you just need to update how your internal obj is built out, and not everything downstream too

17:10 <SamantazFox> yeah, that's mostly what we're doing

17:10 <FromGitter> <Blacksmoke16> 👍 cool

17:10 <SamantazFox> depends on where you're looking, though xD

17:10 <FromGitter> <Blacksmoke16> oh boy 🙈

17:11 <SamantazFox> https://github.com/iv-org/invidious/blob/master/src/invidious/comments.cr#L59-L254

17:11 <SamantazFox> This is terrible, and needs to be reworked

17:12 <SamantazFox> https://github.com/iv-org/invidious/blob/master/src/invidious/yt_backend/extractors.cr

17:12 <SamantazFox> This has been reworked ^

17:12 <FromGitter> <Blacksmoke16> yea that looks a lot more sane

17:13 <SamantazFox> yeaaah xD

17:13 <SamantazFox> slowly, we've been rewriting some large chunks

17:16 <FromGitter> <Blacksmoke16> glad to hear

17:16 <FromGitter> <Blacksmoke16> negotiation component working out well still for ya? :P

17:19 <SamantazFox> Seems so

17:19 <SamantazFox> nobody has been complaining x)

17:20 <FromGitter> <Blacksmoke16> 💪 perfect

22:34 <FromGitter> <ismasan> Hi. Hoping someone can point me in the right direction here: I have a parent Event class with many sub-classes. I want to store records for those classes in a Postgres table. Then when querying I want to deserialize each row into the appropriate sub-class. I'm guessing this is a common use case. Thanks in advance everyone!

22:46 <FromGitter> <Blacksmoke16> Using the raw db driver, or an orm?

22:52 <FromGitter> <ismasan> raw PG driver

22:52 <FromGitter> <Blacksmoke16> also using https://crystal-lang.github.io/crystal-db/api/0.11.0/DB/Serializable.html ?

22:52 <FromGitter> <ismasan> That's what I'm trying ATM, but I'm open to alternatives

22:53 <FromGitter> <ismasan> I get how to deserialize rows into a single class (MyClass.from_rs(result_set))

22:54 <FromGitter> <ismasan> but not sure how to deserialize into different types.

22:54 <FromGitter> <Blacksmoke16> okay, so what i think you could do is override `.from_rs` on the abstract type, have the discriminator column always first in your queries, do like `disriminator = rs.read String`, then use that string over a case, then doing `SubType.from_rs rs` on the right type

22:54 <FromGitter> <ismasan> To be clear in my PG table I have a `type` varchar column. My idea was to use that somehow to resolve which class to deserialize the row into.

22:55 <FromGitter> <ismasan> right right that's what I was starting to try now, thanks

22:56 <FromGitter> <ismasan> I'm declaring these types via a simple macro so perhaps I could generate the case statement there.

22:57 <FromGitter> <Blacksmoke16> probably yea

22:57 <FromGitter> <Blacksmoke16> have options

23:11 <FromGitter> <ismasan> Thanks!