Tag Info

New answers tagged

2

You are being squeezed in both directions, with tricky input and a tricky back-end. In an ideal world, you'd challenge some of these constraints, but I get the impression you won't get anywhere. The algorithm you describe sounds like your only option, although I think it can be improved on a little. Call listTransactions and store all transactions in a ...


3

I cannot be sure that each CSV file has only been processed once... You might want to attempt to solve your question by handling this first. If I am getting this right, the crux of your problem doesn't appear to be individual duplicate transactions (since you mentioned "I know for sure that there are no duplicate records in each CSV file"), but to ...


2

Considering you stated that it is about REST API, think that each call to the API will result in some network traffic, where latency and transfer time apply. So I would say the less calls to the API you make (store results in memory to search through), the better. However, when you work with the API, you don't always have a choice: if the API itself is not ...


3

Maintainability trumps all. Unless you have a pressing reason not to, follow the conventions as they appear in the reference material. In this case, the first Google hit is the documentation for validations at rubyonrails.org, which shows a strong preference to the validates form. The only counter example I could find was validates_associated, which makes ...


0

You have a domain model that encapsulates validation and business logic, and that is no bad thing. Consider what 'hexagonal' architecture would imply for your design. Specifically, it would recommend that you design an interface to your persistence layer, allowing different persistence mechanisms to be plugged in as adapters. When performing the business ...



Top 50 recent answers are included