You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, congratulations on the amazing initiative. This is a much-needed project.
I have noticed that there are not too many columns in the default-generated setup (if I just naively boot up carp). Is this intentional, ie. to keep it unopinionated and slim?
It would be nice to have columns like block_time in transactions out-of-the-box. There could be two setups, a slim one and an opinionated one.
The text was updated successfully, but these errors were encountered:
Yes, this is intentional to keep it slim (we try and only store columns that are necessary for joins)
If you want to add extra columns for information, you can create a custom task that adds this extra information to a new table so that only you will need to synchronize it.
For blocks specifically, right now we don't store the block cbor in the database. I did this as an optimization since block cbor is quite large so it would increase the size of the database quite significantly. If you want the full block cbor, one way you could do it is add a new column to the existing table called "payload" and then make that it only gets filled in the Block task has a specific parameter set (so only people who enable the parameter have to deal with it)
Hello,
First of all, congratulations on the amazing initiative. This is a much-needed project.
I have noticed that there are not too many columns in the default-generated setup (if I just naively boot up carp). Is this intentional, ie. to keep it unopinionated and slim?
It would be nice to have columns like
block_time
in transactions out-of-the-box. There could be two setups, a slim one and an opinionated one.The text was updated successfully, but these errors were encountered: