All threads / Code Review: Run Number Refactoring Discussion

Ask A Question

Notifications

You’re not receiving notifications from this thread.

Code Review: Run Number Refactoring Discussion

Very useful, code review series is awesome

Reply

This was a very helpful episode. A thought for future code review episodes -- if you started with the original code and some unit tests you could show that your refactored code produces the same result. Also you'd be able to test the future dates without changing your computer's date.

+1 for starting with tests on next refactoring episode.

Reply

I enjoyed this as well. Do you want Rails only code samples or Ruby code samples would help as well?

Either one would be great or JS samples even!

Check your inbox, sent you a total mess, enjoy...

Reply

I don't have access to the full episode, but it sounds like what you need here is the little known Ruby method String#succ. I thought I'd just put this out there ;)

Sorta useful but if we wanted a simple increment always we could just use the database for that. Since we have more logic like years restart the count (or the numbers could be not successive in a lot of cases) that won't help in every case.

Always great to use those little ruby niceties when you can though! Thanks for the reminder!

Reply

I vote more of these. Very useful!

Reply

What if iwant to use that run number for example on a transaction number. I think theres a chance to have the same last number on multiple request executed at the same time . Is active base locking the best solution or there is other option?

I didn't have time to get into that at all. One thing is that if you have a database unique index, then the database won't accept duplicate numbers which is good. You would probably want to add a "retry" in so that you could increment again and try that number maybe a few times.

Another option is to lock the table during the insert(make transaction as small as possible) act_as_seuenced gem approach.

Adding unique index with retry can behave wonky depending on the dataset size and number of concurrent transactions trying to insert. You could end up retrying to the infinity :)

Reply
Masud Rana Hossain ·

Code review sounds awesome!

Hell, I would pay you to do sessions WITH me going over my app.

Reply
spaquet ·

I would have been great to measure gain in performance after refactoring. I would be surprise that the refactored methods are not more efficiency than the original one.

Reply
Giancarlo Corzo ·

+1 for this series, I like a lot your thought process and how you incrementally start fixing the problem

Reply

Awesome episode dude!

I still got one question. Let's say I want to add this logic to an existing model with some existing entries in the database. How would I update them when I deploy the app?

For that, you'd probably want to build a Rake task to convert the existing data. For example, you'd want to probably use regex to parse out the existing strings into their parts and then reformat them with the new version. You don't want to run it through the new process exactly, so you'd end up writing some one-time-use code for this which makes the most sense to do in Rake or something similar.

Reply

Just watching this Episode Chris and I must say I love it.

I look forward to watching more.

I hope you still do Refactorings!

Reply
Join the discussion

Want to stay up-to-date with Ruby on Rails?

Join 37,629+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.

    logo Created with Sketch.

    Ruby on Rails tutorials, guides, and screencasts for web developers learning Ruby, Rails, Javascript, Turbolinks, Stimulus.js, Vue.js, and more. Icons by Icons8

    © 2020 GoRails, LLC. All rights reserved.