I use CoPilot inside Github. I spent the $100 for the year to get premium services. I compared GPT40, Claude Sonnet 3.7 Thinking and Gemini Pro 2.5. I found Gemini Pro to provide a response so accurate and good that I had to share it.
Here's a clip of the Gemini Pro response:
Copilot said: Okay, let's break down this two-table versioning
Okay, let's break down this two-table versioning strategy within the Wappler context, focusing on best practices using Server Connect and MariaDB.
Environment: Wappler v7b23, Node.js, MariaDB, Bootstrap v5.3
Goal: Implement versioning for t_contact_communication_log records associated with an m_communications update process.
Analysis of Proposed Steps & Best Practices
Here's how to approach your proposed steps using Wappler's Server Connect, incorporating best practices:
Step 1: OnClick Versioning Process (Server Connect API Action)
This should be a single Server Connect API action triggered by the "Edit" button's OnClick event.
- 1.a. Multi-record Query:
- Wappler Implementation: Use the Database Actions -> Database Query step.
- Query: SELECT * FROM t_contact_communication_log WHERE comm_id = :P1 AND contact_id = :P2
- Parameters: Define :P1 bound to {{$_POST.comm_id}} and :P2 bound to {{$_POST.contact_id}} (assuming these are passed from the client).
- Output: Ensure this step outputs its data (e.g., name it query_master_logs).
- 1.b. Repeat Insert into Version Table:
- Wappler Implementation: Add a Core Actions -> Repeat step after the query.
- Expression: Set the Repeat's expression to the output of the query step: {{query_master_logs}}.
- Inside the Repeat: Add a Database Actions -> Database Insert step.
- Table: t_contact_communication_log_version.
- Fields: Map the fields from the current item in the repeat ({{$value.field_name}}) to the corresponding columns in the version table.
- contact_log_id: {{$value.contact_log_id}}
- request_id: {{$value.request_id}}
- ... (map all relevant fields from the master table)
- version_status: Set directly to 'in-progress' (or similar).
- version_modified_date: Use Wappler's Server Data Bindings: {{NOW}} or {{$_SERVER.REQUEST_TIME.toDateTime()}}.
- created_by: Use the logged-in user's ID, likely from a session variable: {{$_SESSION.user_id}} (adjust based on your session setup).
- Output: The Insert step inside the repeat will output the identity (the new primary key of the inserted version record) if t_contact_communication_log_version has an auto-incrementing primary key (which is recommended - see Table Structure notes below).
Full Backend? Absolutely! With the schema, I can outline: