Conversation
WalkthroughThe changes introduce a persistent database connection architecture, add CLI-based user login and interactive menu system with multiple database operations (list missions, fetch by ID, count by year, account management), add slf4j-simple logging dependency, and update the Maven build configuration with classpath and main class manifest settings. Changes
Sequence DiagramsequenceDiagram
actor User
participant CLI as Main (CLI)
participant DB as Database
User->>CLI: Start application
CLI->>DB: Establish connection
DB-->>CLI: Connection ready
CLI->>User: Prompt username/password
User->>CLI: Enter credentials
CLI->>DB: Query accounts table<br/>(login validation)
DB-->>CLI: User found (or not found)
alt Login Success
CLI->>User: Display menu
loop Menu Loop
User->>CLI: Select operation<br/>(1-8 or 9 to exit)
alt List Missions
CLI->>DB: SELECT moon_mission
DB-->>CLI: Mission data
CLI->>User: Display missions
else Fetch by ID
CLI->>User: Prompt mission ID
User->>CLI: Enter ID
CLI->>DB: SELECT WHERE id=?
DB-->>CLI: Mission details
CLI->>User: Display mission
else Count by Year
CLI->>User: Prompt year
User->>CLI: Enter year
CLI->>DB: COUNT WHERE year=?
DB-->>CLI: Count result
CLI->>User: Display count
else Account Operations
CLI->>DB: INSERT/UPDATE/DELETE account
DB-->>CLI: Operation result
CLI->>User: Confirm operation
else Exit
CLI->>User: Goodbye
CLI->>DB: Close connection
end
end
else Login Failure
CLI->>User: Display error message
CLI->>DB: Close connection
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (5)
src/main/java/com/example/Main.java (5)
100-110: Menu text mostly matches spec; consider aligning wording more closelyFunctionally the menu is fine and options map 1:1 to the required operations. To minimize surprises with the tests and keep the UX aligned with the README, you might consider:
- Making option 2 text closer to the spec, e.g.
Get a moon mission by mission_id.- Optionally dropping or adjusting the
" ---> MENU <--- "header if tests compare menu output strictly.These are cosmetic, not functional.
112-126: Listing missions is correct; optional: add deterministic ordering
listMoonMissionsselectsspacecraftfrommoon_missionand prints each row, which is exactly what’s needed. If you want fully deterministic output (useful for tests), you could add anORDER BY(for example, bymission_id):- String sql = "SELECT spacecraft FROM moon_mission"; + String sql = "SELECT spacecraft FROM moon_mission ORDER BY mission_id";Not required if the tests don’t care about order.
174-205: Account creation flow matches assignment; note about real‑world password handlingThe
createAccountmethod prompts for first name, last name, ssn, and password and inserts them with a prepared statement, then prints"created". That aligns well with the described behavior for option 4.For the assignment this is fine; just keep in mind that in a real application you’d never store plaintext passwords or SSNs like this—hashing and strong access controls would be required.
208-228: Updating password works; optional feedback when no rows are affected
updatePasswordperforms a parameterizedUPDATEonpasswordbyuser_idand prints"updated"unconditionally. That’s functionally acceptable for the lab.If you want slightly better UX, you could check
executeUpdate()’s return value and print a different message whenuser_iddoesn’t exist, but that’s not required by the assignment.
230-246: Delete account implementation is straightforward
deleteAccountdeletes byuser_idusing a prepared statement and prints"deleted". This satisfies the option 6 requirement. Same as with update, you might later distinguish between “deleted” vs “no such user”, but it’s perfectly fine for the lab as‑is.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
README.md(1 hunks)pom.xml(1 hunks)src/main/java/com/example/Main.java(2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/main/java/com/example/Main.java (1)
src/main/java/com/example/DevDatabaseInitializer.java (1)
DevDatabaseInitializer(6-24)
🔇 Additional comments (5)
README.md (1)
1-1: Badge addition is fineThe new GitHub Classroom “Review Assignment Due Date” badge is purely informational and doesn’t affect build or runtime behavior. No changes needed.
src/main/java/com/example/Main.java (3)
3-10: Single sharedConnectionis fine for this CLI use caseUsing a single
Connectionfield that’s initialized once inrun()and reused across the helpers keeps the implementation simple and matches the assignment’s level. No changes strictly required here.
83-96: Login implementation againstaccounttable looks good
logincorrectly uses a prepared statement with parameters onnameandpassword, returningtrueon the first match and wrapping SQL errors in a runtime exception. This matches the described behavior and avoids SQL injection. No changes needed here.
33-80: Consider closing the DB connection on exit and double‑check user‑visible stringsThe connection is opened and stored but never explicitly closed; in a short‑lived CLI this isn't a big problem, but it's still good practice to close it once the login/menu loop is done (e.g. in a
finallyblock around the interactive part ofrun()).Also, some messages are test‑sensitive per the README (e.g. wording around
invalid). You might want to align exact strings with the assignment text (e.g. ensuring the wordinvalidappears in lower case where required) to avoid brittle test failures.pom.xml (1)
49-53: [rewritten comment]
[classification tag]
| // todo: choice 2 - Get mission by ID | ||
| private void getMoonMissionById(Scanner scanner) { | ||
| System.out.print("mission_id: "); | ||
| int id = Integer.parseInt(scanner.nextLine()); | ||
|
|
||
| String sql = "SELECT * FROM moon_mission WHERE mission_id = ?"; | ||
|
|
||
| try (PreparedStatement stmt = connection.prepareStatement(sql)) { | ||
| stmt.setInt(1, id); | ||
| ResultSet rs = stmt.executeQuery(); | ||
|
|
||
| if (rs.next()) { | ||
| System.out.println( | ||
| rs.getInt("mission_id") + " " + | ||
| rs.getString("spacecraft") + " " + | ||
| rs.getString("launch_date") | ||
| ); | ||
| System.out.println("------------"); | ||
| } else { | ||
| System.out.println("Invalid username or password"); | ||
| } | ||
|
|
||
| } catch (SQLException e) { | ||
| throw new RuntimeException(e); | ||
| } | ||
| } |
There was a problem hiding this comment.
Wrong error message when mission ID is not found
In getMoonMissionById, the else branch currently prints:
System.out.println("Invalid username or password");This is misleading in the context of looking up a mission and will confuse users (and likely tests that expect a mission‑specific message).
Apply a small fix like:
- } else {
- System.out.println("Invalid username or password");
- }
+ } else {
+ System.out.println("No mission found for that id");
+ }Optionally, you may also want to validate that the entered ID is numeric and handle NumberFormatException with a simple invalid message, but that’s not strictly required by the assignment.
🤖 Prompt for AI Agents
In src/main/java/com/example/Main.java around lines 128 to 153, the else branch
prints an unrelated "Invalid username or password" message when no mission is
found; change that message to something mission‑appropriate (e.g., "Mission not
found" or "No mission with that ID") so users/tests get the correct feedback,
and optionally add a NumberFormatException catch around parsing the input to
print a simple "Invalid mission ID" message if non‑numeric input is entered.
| // todo: choice 3 - Count missions by year | ||
| private void countMissionsByYear(Scanner scanner) { | ||
| System.out.print("Total missions for 2019: "); | ||
| int year = Integer.parseInt(scanner.nextLine()); | ||
|
|
||
| String sql = "SELECT COUNT(*) FROM moon_mission WHERE YEAR(launch_date) = ?"; | ||
|
|
||
| try (PreparedStatement stmt = connection.prepareStatement(sql)) { | ||
| stmt.setInt(1, year); | ||
| ResultSet rs = stmt.executeQuery(); | ||
| rs.next(); | ||
| System.out.println(rs.getInt(1)); | ||
|
|
||
| } catch (SQLException e) { | ||
| throw new RuntimeException(e); | ||
| } | ||
| } |
There was a problem hiding this comment.
Prompt for year should not hardcode 2019
countMissionsByYear currently prompts:
System.out.print("Total missions for 2019: ");but then reads an arbitrary year and queries using that year. This conflicts with the “given year” requirement and can be confusing.
A clearer and spec‑aligned version would be:
- System.out.print("Total missions for 2019: ");
+ System.out.print("year: ");
int year = Integer.parseInt(scanner.nextLine());The rest of the query logic (using YEAR(launch_date) and printing the count) looks good.
🤖 Prompt for AI Agents
In src/main/java/com/example/Main.java around lines 156 to 172, the prompt
string currently hardcodes "Total missions for 2019: " which is inconsistent
with reading an arbitrary year; change the prompt to a generic, accurate message
(for example "Enter year: " or "Total missions for year: ") so the prompt is
shown before reading input and matches the year being parsed and used in the
query.
Summary by CodeRabbit
Documentation
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.