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=-0.8 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NO_DNS_FOR_FROM,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by gnuweeb.org (Postfix) with ESMTPSA id 01A857F901 for ; Tue, 28 Jun 2022 08:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=default; t=1656403408; bh=LrZIAhQasQ1IBUW1UAfhASYzy34/+zSwOfYavoYVVYs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=o/KfnLQqPtLS27Dw2OtuWnhylBaFPo3fj/kb/LNFwtXjOG8rbk1PyGKSk1saMvwj1 Qdf47oBNre7BxRvqMSBYFd0KAsxf88uLhhI78XilwO0RqWMhwId4b7mbUDe4C4SZbA B/kzwD8N/cWmTTpKrhYpYPArrGh2MUMMF3yfe4/zSQJlg3BxmjC+IdL64l07TMkFXz guuLp/oH+0Va0fKgT7RgWtpcu2dlH/yvnXGw5oauJVKYSS+XeWJPZAFLR5ewpFLRzD 0TEm7VvgLbLkxGTNElQ5kRGUJ7JnQkoMPjnGFvobNG6clMbFDpD/5P6ZpD1x2WR4ku cxYwiXU86e+XA== Received: by mail-lf1-f52.google.com with SMTP id f39so20888580lfv.3 for ; Tue, 28 Jun 2022 01:03:27 -0700 (PDT) X-Gm-Message-State: AJIora/kfwlIEy7600zSUGyjb+EoXnKyIVIt51ydp5iykXYxnMGRWFeY rxSVWuprnTd3WmljCsR5VgmHrRjaQL4T8mySYO0= X-Google-Smtp-Source: AGRyM1vokiiHcmSS646CaL/QVMg5J+mraWmbq+pLY4mvgs9f2WRkbdeUmR5RpyLkGq+0Ife8JhN9LZszT0aL8fWVtJA= X-Received: by 2002:a05:6512:130b:b0:47f:6622:c189 with SMTP id x11-20020a056512130b00b0047f6622c189mr10493291lfu.258.1656403406002; Tue, 28 Jun 2022 01:03:26 -0700 (PDT) MIME-Version: 1.0 References: <20220628062139.262361-1-alviro.iskandar@gnuweeb.org> <20220628062139.262361-2-alviro.iskandar@gnuweeb.org> <197e0152-a743-840d-11bc-3dcf1a72acdb@gnuweeb.org> In-Reply-To: From: Alviro Iskandar Setiawan Date: Tue, 28 Jun 2022 15:03:14 +0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v1 1/1] db: Create starting DDL for saving transaction To: Ammar Faizi Cc: "GNU/Weeb Mailing List" Content-Type: text/plain; charset="UTF-8" List-Id: 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/ ] 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 -- Viro