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

[Ammar Faizi <ammarfaizi2@gnuweeb.org>]

On 6/28/22 3:03 PM, Alviro Iskandar Setiawan wrote:
> On Tue, Jun 28, 2022 at 2:47 PM Ammar Faizi wrote:
>> 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 [sic] no longer find the
>> parent ID because the SHA1 is not sequential, but our primary key is.
> 
> [ sic: s/can't/can/ ]

Heh, this is my first time seeing someone using [sic] in email.

> ic ic, i will do it.
> 
>> 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.
> 
> I will send v2 with that change later.
> 
> tq

Great, thanks!

-- 
Ammar Faizi