pool updates: new column indicating the type of an update

[robinboening]

Is your feature request related to a problem? Please describe.

Currently its not very simple to understand what type of pool update I am looking at.

Describe the solution you'd like

It'd be very helpful to be crystal clear about what type of update I am currently dealing with. This could be done by introducing a new enum column with values like registration, update, deregistration.

Describe alternatives you've considered

Right now I can assume the types (except for deregistrations, see #240 / #241)

• I can assume the very first update item in the list is the pool registration
• I can assume any other item after the first is an update for pool params or relays (only until 240 / 241 are fixed)
• Once 240 and 241 are fixed I might be able to assume deregistrations by retiring_epoch (yet to see)

Another alternative is to follow the transactions referenced in the update items and look for certificates. If there is a registration cert I know its a registration, if there is a deregistration cert I know its a dereg, if none of them is found I know it's a param/relay update. This is cumbersome as it means n+1 requests and requires a bunch of code.

[rdlrt]

Just a note around update, there isnt necessarily a difference on-chain between a registration or an update certificate.

While I see the advantage of coming up with such an isolation, a natural consequence of adding this will then also need handling edge cases - for which the assumed logic of registration vs update may not necessarily hold true. Off the head, I would imagine this would need to then also handle cases where pool is re-registered (deregister and register within an epoch), updated within an epoch or re-registered across epochs, which can get a bit confusing - as against simply providing chain status of register vs retire and let the logic for whether it's an update or not be allowed on clientside, as Koios will be providing chain info rather than an 'overlay' of the same data - unless there is unanimous of request to change the behaviour from consumers

Splitting this will also potentially start giving birth to artificially created information on Koios that might be inconsistent from other chain indexers.

(PS: There is an isolated pool_registrations and pool_retirements already added to v1 - while we'd also be fixing pool_updates in v1 as part of linked issue)

Do you think this would work fine?

[robinboening]

Thank you for the elaborate response. You're much deeper in the guts of the data structures than I am, so I'll just trust you on the edge case issue :) In my naive thinking I was assuming checking the certificates would make it easy to determine the type and since every update is a snapshot of the current state it wouldn't make a difference if there is one or many updates of any type per epoch.

I think pool_registrations and pool_retirements are great additions, but for specific use cases. In my case I wouldn't use them and prefer pool_updates providing me with all the information as I care about all of them.

I am closing this for now. Maybe something to bring up again at a later point.

Thank you!