From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,NO_DNS_FOR_FROM, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from [192.168.88.254] (unknown [125.160.108.65]) by gnuweeb.org (Postfix) with ESMTPSA id CB8A17FA04; Tue, 28 Jun 2022 07:47:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=default; t=1656402427; bh=0MGo2QFeirx4uWzPfJmk0radv+hXkhjX5an8gV0O6U4=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=g66xVAeHl+AdiiXAJsVEUE0xfI5JRDr+sRknz9g8JjmJyQw9rsxiOD0U0JuLqtoXB j8YoYsT3TGjP+qZ4cl1Yh4/jONOrPBjyr8gu2I1CuUz6Pokavn1Fey869pWtTkYXbO T/2FJIZzG/b4EbAl0LGFw6TLHCXuuqU5vzdgZTwsO4Zo5cD2q52glkBxkZurki/UBm rk1wT+btkUlPv54x7HyCa4p3tfdacU+iiFCStQiWu8pBJcWVvbIBihnXBFLLvKjgwO i7Q+6sltBR+R6Ox5RfziNN44lwGk5k8Zb9jjB656XdCyDkfCDePXCqDUZgDdtSBCiI UynAAgNgCrofQ== Message-ID: Date: Tue, 28 Jun 2022 14:47:00 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US To: Alviro Iskandar Setiawan Cc: GNU/Weeb Mailing List References: <20220628062139.262361-1-alviro.iskandar@gnuweeb.org> <20220628062139.262361-2-alviro.iskandar@gnuweeb.org> <197e0152-a743-840d-11bc-3dcf1a72acdb@gnuweeb.org> From: Ammar Faizi Subject: Re: [RFC PATCH v1 1/1] db: Create starting DDL for saving transaction In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: 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