🏆Capstone project: Project: Build Safe Member Change Functions

The member table needs the same careful operations you built for items. This time you will choose all four statements and parameter mappings yourself, using member fields rather than copying item-specific names or positions.

Each member row has this exact order:

Open member_changes.py. It contains four function definitions. Keep their names and arguments, and make each one behave like this:

• find_member(connection, member_code) selects id, member_code, name, loan_limit for one bound code and returns .fetchone().

• add_member(connection, member) inserts the four explicit columns with four placeholders and returns the insert cursor’s immediate rowcount.

• change_loan_limit(connection, member_code, loan_limit) updates loan_limit where the bound code matches. Its values are (loan_limit, member_code), and it returns immediate rowcount.

• remove_member(connection, member_code) deletes where the bound code matches and returns immediate rowcount.

Write a fixed triple-quoted statement inside each function, then call connection.execute(statement, values) through the supplied open connection. Do not open, close, or replace that connection.

A useful order is search, insert, update, then delete. The four parameter tuples then grow naturally from what you already know:

For a code such as "M'50", the apostrophe stays inside the Python value in each case. It never becomes part of the SQL text, so searching, changing, and removing that member all use the same safe boundary.

Run demonstrates one complete sequence with literal calls. It finds Riley, then calls:

add_member(connection, (13, "M'50", "Ari O'Neil", 2.5))
change_loan_limit(connection, "M'50", 4.5)
remove_member(connection, "M'50")

The expected returns are 1, 1, and 1. Searches before and after show the complete tuple, its changed limit, and finally None. The same open connection carries every observation.

The run also uses "X' OR 1=1 --" as a missing code. Both change functions should return 0, and Sam’s M-23 row must remain unchanged. Preserve each complete code as a bound value.

Submit tests every function separately and in sequence with unseen IDs, names, apostrophes, SQL-looking text, and positive whole and fractional limits. The table’s existing rules may raise their normal database error for duplicate IDs, duplicate codes, or invalid limits; do not hide or relabel those errors.

Work one function at a time. First make its ordinary case visible, then check the missing or hostile-looking value, and only then move on. The finished module gives the member side of the lending project the same narrow, observable, and safely bound changes as the item side.