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

sean carnahan: 0013 - [backend] add payment method retrieve api #41

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

seancarnahan
Copy link

No description provided.

import com.bravo.user.dao.model.Payment;

@Repository
public interface PaymentRepository extends JpaRepository<Payment, String> {

Choose a reason for hiding this comment

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

This should be extending PagingAndSortingRepository. And the findByUserId() method should include a Pageable parameter.

Copy link
Author

Choose a reason for hiding this comment

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

Hi Darrin,

Good call on the paging. Yeah at first I had it set up with the paging specifications, but then took it out because it didn't look like the requirements asked for paging. So went ahead and added it back in and updated the unit tests. I added the screenshots in the reply for the other comment. Thanks!

Choose a reason for hiding this comment

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

Thanks @seancarnahan !! Yes that's exactly what I was looking for. You took it a step further with JpaSpecificationExecutor. The bottom line was to tell the Repository how to page the results (which can be done in several ways). Looks better, thank u.

this.resourceMapper = resourceMapper;
}

public List<PaymentDto> retrieveByUserId(final String userId) {

Choose a reason for hiding this comment

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

This method should accept a Pageable parameter

Copy link
Author

Choose a reason for hiding this comment

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

image

Screen Shot 2022-12-29 at 12 43 20 PM

image

@@ -9,7 +9,7 @@ spring:
password: ${DB_PASSWORD:password}
username: ${DB_USERNAME:sa}
url: ${DB_URL:jdbc:h2:mem:testdb}
h2.console.enabled: false
h2.console.enabled: true

Choose a reason for hiding this comment

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

Like this for the testing version of the appliation.yml. In the root, is this a security issue?

Choose a reason for hiding this comment

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

Agreed. I was thinking this was done to do queries and/or look at the schema. But it should only be done locally when working with the code.

Copy link
Author

Choose a reason for hiding this comment

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

Very true, nice catch. Should not be checked into main branch. Removed

@@ -648,3 +648,8 @@ insert into address (id, user_id, line1, line2, city, state, zip) values
('42f33d30-f3f8-4743-a94e-4db11fdb747d', '008a4215-0b1d-445e-b655-a964039cbb5a', '412 Maple St', null, 'Dowagiac', 'Michigan', '49047'),
('579872ec-46f8-46b5-b809-d0724d965f0e', '00963d9b-f884-485e-9455-fcf30c6ac379', '237 Mountain Ter', 'Apt 10', 'Odenville', 'Alabama', '35120'),
('95a983d0-ba0e-4f30-afb6-667d4724b253', '00963d9b-f884-485e-9455-fcf30c6ac379', '107 Annettes Ct', null, 'Aydlett', 'North Carolina', '27916');

insert into payment (id, user_id, card_number, expiry_month, expiry_year) values
('payment-1', '008a4215-0b1d-445e-b655-a964039cbb5a', 'card-number-1', 12, 2027),

Choose a reason for hiding this comment

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

Is there potential for a card number that is not only digits? I've not seen that.

Choose a reason for hiding this comment

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

LOL. Yeah I noticed these "non-numeric" card #'s as well. Maybe he was just trying to make it obvious that's it's a card #, without needing to look at which column the value is mapped to on above line. My best guess here.

Copy link
Author

Choose a reason for hiding this comment

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

yeah was just trying to make it obvious haha. But it is also a varchar within the schema:

create table payment (
    id varchar(60) primary key,
    user_id varchar(60) not null,
    card_number varchar(16) not null unique,
    expiry_month integer not null,
    expiry_year integer not null,
    updated timestamp not null default current_timestamp()
);

In practice, typically we could get test credit card numbers from creditcard providers.

Choose a reason for hiding this comment

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

Nice. Yeah, I was on a project where we did the actual checking for the number transposing and modulo checks. That's a bit over the top for this :) . Using all the rules here https://www.validcreditcardnumber.com/ or here https://developer.visa.com/capabilities/pav/reference#tag/Payment-Account-Validation-API/operation/Card%20Validation_v1%20-%20Latest. I would've non-varchared it because of potential savings in disk usage. That's likely negligible up to a few million records though. So no biggie here.

Comment on lines +101 to +105
private PaymentDto createPaymentDto(final String id) {
final PaymentDto payment = new PaymentDto();
payment.setId(id);
return payment;
}

Choose a reason for hiding this comment

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

This sets the payment id. Are the other fields checked in these tests?

Copy link
Author

Choose a reason for hiding this comment

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

Was mainly just following the structure of the UserServiceTest, but we could and should test other fields as well.

Choose a reason for hiding this comment

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

The code in the repo isn't necessarily correct :) . I have been following Uncle Bob pretty closely and was a bit shocked by his calling untested code "immoral" https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073. While I think that is a bit overly harsh, from our business client's perspective it's of huge importance. Thanks for the replies. I put in a good word about you to Issac. :)

Copy link
Author

Choose a reason for hiding this comment

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

Great, thank you so much! And will have to check out that book and couldn't agree more that what matters for the client is what matters most.

@seancarnahan seancarnahan requested review from tlynema-bravolt and darrinamway and removed request for tlynema-bravolt and darrinamway December 30, 2022 19:25
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.

3 participants