message_id should not be nullable

[csgui]

message_id should not be nullable.

The tables mock_proposals and mock_signatures have an UNIQUE constraint on message_id, which suggests a one-to-one relationship between messages and mock_proposals, as well as between messages and mock_signatures. Therefore, message_id is used as a foreign key and should not allow NULL values.

[smcclellan]

@zone117x Is it possible for a mock proposal or mock signature to have no message (no corresponding entry in the messages table)?

[rafaelcr]

@csgui The mock proposals table stores peer info data, which sometimes belongs directly to a message and some other times it belongs to a mock signature. In the latter case, the message is attached to the signature itself, not the peer info.

(I consolidated these two into a single table to avoid repetition since it's practically the same schema)

If you add this constraint, chainhook will crash when inserting mock signatures.

[csgui]

@rafaelcr Thanks for the info!

I see the advantages of this approach in reducing schema complexity and avoiding duplicate table structures. However, in terms of data integrity - if a message is deleted (considering the CASCADE), we lose the peer info. But what if this peer info was actually related to a signature? Is this a real possibility?

[rafaelcr]

@csgui not really. Messages write the data they need in that moment onto the DB, i.e. they don't look for repeated peer info so they can mark the relationship if it existed previously (it actually won't ever find repeated peer info because it writes block data in the same row).

If a message gets deleted and deletes peer info with it, no other data will be affected.

[csgui]

Closing this PR, as this approach does not adequately address the problem. I will tackle the issue in a separate PR.