Re: [RFC PATCH v1 1/1] db: Create starting DDL for saving transaction

[Ammar Faizi <ammarfaizi2@gnuweeb.org>]

On 6/28/22 2:31 PM, Alviro Iskandar Setiawan wrote:
> On Tue, Jun 28, 2022 at 2:27 PM Ammar Faizi wrote:
>> Hi Al,
>>
>> On 6/28/22 1:21 PM, Alviro Iskandar Setiawan wrote:
>>> +CREATE TABLE `transactions` (
>>> +  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
>>> +  `trx_id` binary(20) NOT NULL,
>>> +  `parent_trx_id` binary(20) NOT NULL,
>>
>> My worry on this is: you reference a parent transaction ID with the
>> sha1 hash, there is no backup if that gets changed. What about using
>> the sequence ID to reference it?
> 
> That should never change, if it ever gets changed, something has gone
> very wrong.

That's not what I mean.

Yes, if we ever had a corruption, something has gone very wrong. But
my point is: if that gets corrupted, you can't no longer find the
parent ID because the SHA1 is not sequential, but our primary key is.

Plus we will be dealing with transaction, which makes the situation
better because the last transaction will never have a smaller seq ID
than the previous transaction, the PK generation is atomic, so the
increment too.

Also, considering space...

You can save more space using the sequence ID, because it's smaller
than SHA1. You can still get the parent SHA1 by doing a simple lookup
with that foreign key. At the end of the day, we get nothing to lose
using seq ID as a reference. We even save more space.

-- 
Ammar Faizi