Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Create escrow_contracts table for escrow contract tracking #143

Closed
wants to merge 5 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
CREATE TYPE IF NOT EXISTS escrow_state AS ENUM ('NEW','ACTIVE','CANCELLED');
AndlerRL marked this conversation as resolved.
Show resolved Hide resolved

CREATE TABLE IF NOT EXISTS escrow_contracts (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

UUID Generation Dependency.
The primary key uses uuid_generate_v4(), which is great for ensuring unique identifiers. However, please ensure that the PostgreSQL extension (typically uuid-ossp) is enabled in your database setup or a prior migration to avoid runtime issues.

engagement_id TEXT UNIQUE NOT NULL,
contract_id TEXT UNIQUE NOT NULL,
project_id UUID NOT NULL REFERENCES projects(id),
contribution_id UUID NOT NULL REFERENCES contributions(id),
payer_address TEXT NOT NULL,
receiver_address TEXT NOT NULL,
Comment on lines +9 to +10
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Address Fields Verification.
The payer_address and receiver_address fields are defined as TEXT and are mandated as NOT NULL. If there are business rules regarding the format or maximum length of these addresses, consider implementing those validations at the application layer or via an additional check constraint.

amount NUMERIC(20,7) NOT NULL,
current_state escrow_state NOT NULL DEFAULT 'NEW',
platform_fee NUMERIC(5,2) NOT NULL,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Platform Fee Constraint Suggestion.
The platform_fee column is defined with a fixed precision, which is appropriate; however, it currently lacks a check constraint to ensure a non-negative value (or to enforce any business-specific upper bounds). Consider adding a constraint if such validations are required.

created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
Comment on lines +14 to +15
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Timestamp Columns Reminder.
Both the created_at and updated_at fields default to CURRENT_TIMESTAMP, which is useful for record creation. Do note that the updated_at column will not automatically update on record modifications. If automatic timestamp updates upon changes are desired, consider implementing a trigger or handling this update within the application logic.

completed_at TIMESTAMP WITH TIME ZONE,
metadata JSONB DEFAULT '{}'::jsonb,
CONSTRAINT valid_escrow_amount CHECK (amount > 0),
CONSTRAINT valid_platform_fee CHECK (platform_fee >= 0)
);

-- Enable Row Level Security (RLS) on the table
ALTER TABLE escrow_contracts ENABLE ROW LEVEL SECURITY;

-- RLS Policy: allow read access to all
CREATE POLICY public_select_escrow_contracts
ON escrow_contracts
FOR SELECT
USING (true);
Comment on lines +22 to +29
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Row Level Security (RLS) and Policy Configuration.
Enabling RLS on the escrow_contracts table and defining a public SELECT policy is a strong move towards enhancing the security posture of the data. Consider reviewing future needs to determine if additional policies—for INSERT, UPDATE, or DELETE operations—are required as the business logic evolves.