Skip to content

Add traffic signals table and solution - #760

Merged
likawther3li merged 4 commits into
mainfrom
feature/86eyt38j9-traffic-signals-kawther
Sep 1, 2026
Merged

Add traffic signals table and solution#760
likawther3li merged 4 commits into
mainfrom
feature/86eyt38j9-traffic-signals-kawther

Conversation

@likawther3li

Copy link
Copy Markdown
Collaborator
  • traffic_signals table to store each signal's state
  • check_and_update_signal_status to move the signal between RED, YELLOW and GREEN based on how much time passed
  • start_signal_watch to start a scheduler job for the signal
  • stop_signal_watch to stop one signal without affecting the others
  • a trigger that starts the signal automatically when a new row is inserted

@github-actions

Copy link
Copy Markdown

Here are the code review comments for the pull request titled "Add traffic signals table and solution":

Code Review Comments

  1. Title Format: The title should start with the Clickup ticket ID (e.g., "86ex6r17g: Add traffic signals table and solution").

  2. Description Clarity: Ensure the description reflects the changes made and uses proper sentence structure for clarity; it currently lacks comprehensive detail.

  3. Indentation Consistency: Lines 3, 4, and beyond have inconsistent indentation. Ensure all lines use 4 spaces consistently.

  4. Unnecessary Blank Lines:

    • Lines 6-8 and 14-17 can be consolidated; there are excessive blank lines.
    • Lines 29-30 could also be formatted without the blank line.
  5. Logical Flow: Review the procedures to ensure no necessary checks (like signal existence) are missed before operations like updating or fetching states.

    • Specifically check check_and_update_signal_status for robustness against invalid IDs.
  6. Redundant Procedures:

    • You have defined the same procedure check_and_update_signal_status multiple times (once at line 12, again at line 19, and again at line 41). This can confuse maintainability. Consider consolidating them into one.
  7. Output Statements: The DBMS_OUTPUT.PUT_LINE calls in procedures can be replaced with appropriate error handling or logs where necessary.

  8. Commit Handling: It’s advisable to avoid using COMMIT within procedures, especially those that are called periodically. Consider allowing the calling context to manage commits to maintain control over transaction boundaries.

  9. Error Handling: In the stop_signal_watch procedure (lines 138-142), ensure error handling is comprehensive, especially for SQL exceptions that can occur when jobs do not exist.

These suggestions aim to improve the code clarity and maintainability, while ensuring consistent formatting and logical correctness throughout the changes made in this pull request.

New%20session%20-%202026-08-31T08%3A50%3A31.457Z
opencode session  |  github run

Mariya-2001
Mariya-2001 previously approved these changes Aug 31, 2026
Comment thread src/main/java/org/example/fromkawther/TrafficSignals/traffic_signals_solution.sql Outdated
…nly calls CREATE_JOB if the job doesn't already exist. Tested by calling it twice for the same signal, no error now
@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown

Code Review Comments

  1. Title Format: The title should start with the Clickup ticket ID (e.g., "86eyt38j9: Add traffic signals table and solution").

  2. Description Clarity: The description currently lacks comprehensive detail. It should clearly reflect all changes made, e.g.:

    • "Added a traffic_signals table to store each signal's state."
    • "Implemented check_and_update_signal_status to update signals between RED, YELLOW, and GREEN based on time passed."
  3. Indentation Consistency: Lines 3, 4, and further down lack consistent indentation. Ensure all lines consistently use 4 spaces.

  4. Unnecessary Blank Lines:

    • Excessive blank lines found between lines 6-8, 14-17, and 29-30. They can be consolidated or removed for cleanliness.
  5. Logical Flow: The procedures should include checks for signal existence before operations like updates or fetching states:

    • Review check_and_update_signal_status (line 12 and later) to ensure it checks validity before proceeding.
  6. Redundant Procedures: The procedure check_and_update_signal_status is defined multiple times (lines 12, 19, 40). Consider consolidating these definitions to avoid confusion.

  7. Output Statements: Replace DBMS_OUTPUT.PUT_LINE calls with appropriate error handling or logging where necessary.

  8. Commit Handling: Avoid using COMMIT within procedures like check_and_update_signal_status (line 63) to maintain control over transaction boundaries.

  9. Error Handling: In stop_signal_watch (lines 138-149), ensure that error handling is proactive, especially around SQL exceptions for non-existent jobs.

These comments aim to enhance clarity, maintainability, and functional correctness in this pull request.

New%20session%20-%202026-09-01T05%3A35%3A26.467Z
opencode session  |  github run

-----read the signal-----
CREATE OR REPLACE PROCEDURE check_and_update_signal_status (p_signal_id IN NUMBER)
AS
v_state traffic_signals.signal_state%TYPE;

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

can't we just mention varchar2 as type instead of signal_state%TYPE ?

@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown

Here are the code review comments based on the provided pull request:

Code Review Comments

  1. Title Format: The title should start with the ClickUp ticket ID. It currently reads as "Add traffic signals table and solution". It should be:

    • Correct Format: 86eyt38j9: Add traffic signals table and solution.
  2. Description Clarity: The description should clearly reflect all changes made. For improved clarity, consider rephrasing as follows:

    • "Added a traffic_signals table to store each signal's state."
    • "Implemented check_and_update_signal_status to manage signals between RED, YELLOW, and GREEN based on timing."
  3. Indentation Consistency: Lines demonstrate inconsistent indentation; all code should use 4 spaces consistently throughout.

  4. Unnecessary Blank Lines:

    • There are excessive blank lines found:
      • Lines 6-8 and 14-17 should be removed for cleaner code.
      • Consolidate lines 29-30 into a single line as well.
  5. Logical Flow: Ensure robustness in procedure checks. Specifically, ensure that:

    • check_and_update_signal_status validates signal existence before updates.
  6. Redundant Procedures: check_and_update_signal_status appears multiple times (lines 12, 19, 40). Consolidate these into a single definition for maintainability.

  7. Output Statements: Consider replacing DBMS_OUTPUT.PUT_LINE statements with appropriate error handling or logging mechanisms for better production practices.

  8. Commit Handling: Avoid issuing COMMIT statements directly within procedures, such as in check_and_update_signal_status on line 63, to maintain transaction control outside of procedure definitions.

  9. Error Handling: In the stop_signal_watch procedure (lines 138-149), ensure robust error handling, especially to check for SQL exceptions for jobs that may not exist.

These comments aim to enhance code quality and maintainability while ensuring consistent formatting and logical correctness in the changes made in this pull request.

New%20session%20-%202026-09-01T08%3A04%3A24.270Z
opencode session  |  github run

@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown

Here are the code review comments based on the provided pull request titled "Add traffic signals table and solution".

Code Review Comments

  1. Title Format:

    • The title should start with the ClickUp ticket ID for clarity and consistency:
      • Correct Format: 86eyt38j9: Add traffic signals table and solution.
  2. Description Clarity:

    • The description should clearly reflect all changes made. It currently reads too concisely; consider rephrasing it for clarity:
      • "Added a traffic_signals table to store each signal's state."
      • "Implemented check_and_update_signal_status to manage signals between RED, YELLOW, and GREEN based on timing."
  3. Indentation Consistency:

    • Lines show inconsistent indentation. Ensure all lines consistently use 4 spaces.
  4. Unnecessary Blank Lines:

    • Remove excessive blank lines between:
      • Lines 6-8
      • Lines 14-17
      • Lines 29-30
  5. Logical Flow:

    • Ensure all procedures validate signal existence prior to updates.
    • Review check_and_update_signal_status to confirm it properly checks for signal validity before processing.
  6. Redundant Procedures:

    • The check_and_update_signal_status procedure appears multiple times (lines 12, 19, 41). Consider consolidating these definitions into a single, clear implementation.
  7. Output Statements:

    • Replace DBMS_OUTPUT.PUT_LINE with appropriate error handling or logging methods for production-readiness.
  8. Commit Handling:

    • Avoid using COMMIT within procedures (e.g., in check_and_update_signal_status on line 63) to maintain control over transaction boundaries.
  9. Error Handling:

    • In the stop_signal_watch procedure (lines 138-149), ensure robust error handling, particularly for SQL exceptions when referencing non-existent jobs.

These suggestions aim to enhance code quality and maintainability while ensuring consistent formatting and logical correctness in the changes made in this pull request.

New%20session%20-%202026-09-01T08%3A06%3A19.445Z
opencode session  |  github run

@likawther3li
likawther3li merged commit 5dabdb9 into main Sep 1, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants