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

[Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>]

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