Let’s say, for example, that I want to create an order form and that I
want to assign an order number to each submitted order form for
tracking purposes. So, I create a little file to store the latest
number. Then when a new order comes in, I grab that number, increment
it by one, assign the incremented number to the order, and finally
replace the number that’s in the file with the new number. My
question is this: Under the Rails conventions, where would be the
appropriate place to locate the file that stores the number?
Since “Rails is a full-stack framework for developing database-backed
web applications…,” [1] the convention is to have an orders table
with an auto-incremented id column. Of course, you could have another
auto-incremented column, e.g., number (if that’s not a reserved word
in Ruby/Rails), so that the id is kept meaningless in the domain.
Thus, each order that you create will be assigned the next number.
Since I assume that you’re storing the orders in a database, why
store the order number in a file?
Since I assume that you’re storing the orders in a database, why
store the order number in a file?
Yep, you got the reason. I’m not using a database for this
hypothetical task. I know I could do it that way. The thing is this.
If (for whatever reason) I decide not to use a database and store the
order number in a file, I’d like to know where under the Rails
conventions, it would be appropriate to locate that file.
Since I assume that you’re storing the orders in a database, why
store the order number in a file?
Yep, you got the reason. I’m not using a database for this
hypothetical task. I know I could do it that way. The thing is this.
If (for whatever reason) I decide not to use a database and store the
order number in a file, I’d like to know where under the Rails
conventions, it would be appropriate to locate that file.
I don’t think rails has a strong opinion since the convention would be
to put it in the db
I don’t think rails has a strong opinion since the convention would be
to put it in the db
I have /app/configs for my own storage of read-only setup files for
stuff I’d rather define in text than code (then load, parse, cache).
However, aside from storage location, you’ll have a much larger issue
of concurrency access. You need to prevent readA-readB-writeB-writeA
or you’ll end up with multiple orders having the same number. In a
classic array of mongrels deployment, or even in the new mod_rails, I
imagine that would be very difficult.
For something with very high volumes of accesses like an auction a
traditional db might be too slow, but designing your own thread_lock
system will be much, much slower, especially in a language like Ruby.
If you’re usually running a big db like MySQL, SQLServer, etc, and
just don’t want the weight, then maybe consider SQLite3 for a case
like this. Something new to learn, but it’s small and fast.
– gw
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.