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 DF8907F901; Tue, 28 Jun 2022 08:07:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=default; t=1656403654; bh=FwrA0OWzdIphRluwH4M3VIp12bezdWtgMZ9s/BEDAJM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jEm7dj2QLqg36MGU2arIF0BX2YsacwIHIYQ3ByI98gTCMEpUrBf03QGLJRZljOuMS BVIJ5og1s2PWYx1sdexeH57EmLYhLKktC5r1+bNLbwXoFynvqVykd8xuNdX95FfwVx 5lA5nbZ1qXaFuZ4yjM5WiSjjKtygCDceE1CbtmEyGVvg1wVfO10ZTnBloPJpS2fStQ K2m6nsqaRul6HR2U1dhkxauvIqS9+cwm8X8XAwQS7qAlX5f3y0RJTRmP1iIrFhMici SpgtX3D9nP3Syd/Jo6Unz1IbdK1B98I6qMz/RM04c/w3o/lBBjJn3K3iyOfE2NFr8V mlZknBz3VtcFg== Message-ID: <399cf5bf-f9f5-05e0-600b-b8fcb03d91aa@gnuweeb.org> Date: Tue, 28 Jun 2022 15:07:22 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [RFC PATCH v1 1/1] db: Create starting DDL for saving transaction 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 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: 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