feat: add plan db scheme

[hbollon]

I used the db scheme available in the TerraVerge repository to which I added a foreign key to the associated bucket (I thought it would be useful if we add support for several simultaneous bucket) and the CreatedAt / UpdatedAt columns

Here is the table that it creates (visualized from pgadmin):

[coveralls]

Coverage decreased (-0.5%) to 13.093% when pulling e44d389 on hbollon:db-scheme-plan into 1165c06 on camptocamp:v2.

[mcanevet]

@hbollon don't we have the lineage in the plan? I guess it would be useful to link it to the states.

[cryptobioz]

Where is the field corresponding to the bucket? Is that the field Source?

[hbollon]

@hbollon don't we have the lineage in the plan? I guess it would be useful to link it to the states.

No it is not in the model currently but it's a good idea I'll add a field for that

Where is the field corresponding to the bucket? Is that the field Source?

The field representing the associated bucket is VersionID. The Source field on the other hand, if I am referring to TerraVerge, is a trace of the system at the origin of the Terraform plan (like the Gitlab pipeline)

[cryptobioz]

The field representing the associated bucket is VersionID. The Source field on the other hand, if I am referring to TerraVerge, is a trace of the system at the origin of the Terraform plan (like the Gitlab pipeline)

Okay, that's great! Regarding the bucket field, would it make sense to name it like BucketID or StateID?

[hbollon]

The field representing the associated bucket is VersionID. The Source field on the other hand, if I am referring to TerraVerge, is a trace of the system at the origin of the Terraform plan (like the Gitlab pipeline)

Okay, that's great! Regarding the bucket field, would it make sense to name it like BucketID or StateID?

I thought the same thing but the structure for the bucket is called Version in the Go code (defined in types/db.go), we would lose readability in the code by renaming this field BucketID while it references a Version no?

[cryptobioz]

You're totally right, I didn't read the whole file... Then I'm okay with what you did :)

@raphink, could you give us some explanation regarding how you store the S3 bucket information?

[hbollon]

Another notable thing that I would have wanted you to validate is the use of the go-gorm/datatypes library used to be able to use a jsonb field for store the raw plan output.
That's ok?

[cryptobioz]

Another notable thing that I would have wanted you to validate is the use of the go-gorm/datatypes library used to be able to use a jsonb field for store the raw plan output.

I guess it's okay for me :)

[hbollon]

I just thought that the CreatedAt and UpdatedAt fields being managed automatically by Gorm during the insertion, we will not have the real date of creation of the plan. Will it be useful to add a field to store it?

[cryptobioz]

Well, if everything is automated, you will have the right creation date. We should keep these fields and let Gorm manage them.

[hbollon]

I think my understanding of the Version structure was wrong, I thought it represented the Bucket but in reality this structure represents the version of a State.
So it seems to me that it is not relevant to have a Belongs To relation on a Plan to a Version right?

I don't understand the comment of this object by the way, "Version is an S3 bucket version", wouldn't it be "a State Version" instead? If I'm not mistaken, with Terraform we don't version Buckets but States files right?

[mcanevet]

Indeed, I guess the link between state and plane should be done on lineage, which is, from my understanding, the unique ID that identifies a workspace. lineage+serial identifies a version of the state. lineage+"execution time" should identify a plan.

[hbollon]

Indeed, I guess the link between state and plane should be done on lineage, which is, from my understanding, the unique ID that identifies a workspace. lineage+serial identifies a version of the state. lineage+"execution time" should identify a plan.

Okay so I removed it. Now this PR should be mergeable if it's all good for you 😄

[raphink]

Let's merge this for now so @hbollon can start working on gorm.v2.