Writing a contract testing tool from scratch -- database design

Continued above , The first step is to design our table structure , My initial idea is to have two watches to hold it , There must be some changes in the future , Because I also write tools while recording .

Design description

The tool should have two pieces of content , The first is the information of the contract , This part records the structure of the contract . The second is the sub contract , All concrete values must be carried by the sub contract , The content of a sub contract is immutable once it is defined . The specific message contents of the contract tool for the consumer and the production end are carried by the sub contract .

Environmental statement

I'm using sqlalchemy This ORM Framework to handle database interaction . The code of the table structure is as follows

from sqlalchemy import Column, String, Integer
from sqlalchemy.ext.declarative import declarative_base

BaseModel = declarative_base()


class ContractStructure(BaseModel):
    __tablename__ = 'contract_structure'
    id = Column(Integer, primary_key=True)
    contract_name = Column(String(500), nullable=False)
    contract_consumer_body = Column(String(10000), nullable=False)
    contract_consumer_keys = Column(String(500), nullable=False)
    contract_provider_body = Column(String(5000), nullable=False)
    contract_stakeholders = Column(String(500), nullable=False)
    contract_child_ids = Column(String(500), nullable=True)
    contract_version = Column(Integer, default=1)
    contract_last_version = Column(String(1), nullable=False, default='Y')
    provider_url = Column(String(100), nullable=True)


class ContractChild(BaseModel):
    __tablename__ = 'contract_child'
    id = Column(Integer, primary_key=True)
    child_id = Column(String(40), nullable=False)
    child_name = Column(String(100), nullable=False)
    contract_id = Column(Integer)
    child_consumer_body = Column(String(10000), nullable=False)
    child_provider_body = Column(String(5000), nullable=False)

Let's explain my design idea one by one

ContractStructure

This table is used to store the contract structure and some contract related information .

• contract_name

Contract name , Generally speaking, names that are easy to recognize are better , such as Consumer-Provider such .

• contract_consumer_body

The structure of contract consumers , That is to say consumer Message sent by the end .

• contract_consumer_keys

The structure of the contract consumer key, Because the structure is immutable in contract testing , Therefore, it must be verified consumer End to end structure key value , To ensure the consistency of message structure

• contract_provider_body

The structure of the contract producer , That is, return to consumer End message structure

• contract_stakeholders

The stakeholders of the contract , Once the contract changes , Objects that the program needs to notify

• contract_child_ids

Of the sub contents of the contract id

• contract_version

Version information of the contract , Once the contract is changed , Then the version should be changed accordingly

• contract_last_version

Mark whether the modified contract is the latest contract

• provider_url

In production url Address , Tools should be able to give provider The client sends the contract content , So you need a field to record url

contract_child

This table is used to store the contents of the sub contract

• child_name

The name corresponding to the sub contract

• contract_id

Of the contract id

• child_consumer_body

The message content of the consumer

• child_provider_body

Message content of the production end

Last

above , We defined the table of the tool , What should be done next is to start writing concrete contract classes .