Forum: Ruby on Rails Application Design

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E94ca0face81fe54d0486b397ea3412d?d=identicon&s=25 Campano, David (Guest)
on 2006-04-24 16:19
(Received via mailing list)
I have a question about how to implement a design in Rails.  I will try
to make this as easy to follow as possible.  First, let's say that I
have an 'Orders' table that has different statuses.  The 3 statuses that
I want to track are 'Submitted', 'Approved', and 'Purchased'.
I also have 3 users of this application.

- User A can submit an order
- User B should only see orders with 'Submitted' status and can
'Approve' orders
- User C should only see 'Submitted and Approved' orders and can
'Purchase' the order

I realize this is more of a workflow question, but I'm trying to figure
out the best way to structure this.

Here is one thought...

Statuses Table
----------------------
ID
Name

Orders Table
---------------------
ID
Name

Orders_Statuses
--------------------
order_id
status_id

Then, I can do a join in the model to only return the correct rows.  Is
this the correct way to do this?  Also, what type of logic should I be
doing in the controller (i.e. Making sure that the Order is approved and
submitted before Purchasing can order it)?
Please see the following link for the BlueCross BlueShield of Tennessee
E-mail
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm
Ff43001ac5fe9805aa6ca2e89d3b7b5d?d=identicon&s=25 Jake Janovetz (janovetz)
on 2006-04-24 16:24
Campano, David wrote:
> I have a question about how to implement a design in Rails.  I will try
> to make this as easy to follow as possible.  First, let's say that I
> have an 'Orders' table that has different statuses.  The 3 statuses that
> I want to track are 'Submitted', 'Approved', and 'Purchased'.
> I also have 3 users of this application.
>
> - User A can submit an order
> - User B should only see orders with 'Submitted' status and can
> 'Approve' orders
> - User C should only see 'Submitted and Approved' orders and can
> 'Purchase' the order
>
> I realize this is more of a workflow question, but I'm trying to figure
> out the best way to structure this.

Your join table would work but to me it makes more sense to have a
single status associated with an order.  Then your Orders table would
just include a status_id column.  You statuses would change:
  1. New  (or just a nil status_id)
  2. Submitted
  3. Approved
  4. Purchased

   Jake
F690ec04b0501b74b033fc64ff4f682b?d=identicon&s=25 Dean Wampler (Guest)
on 2006-04-24 16:29
(Received via mailing list)
Is it correct to assume that "submitted", "approved", and "purchased"
are mutually exclusive "states"? If so, then why not have one table
with a field for this state? You can then structure your queries so
that they select the permitted state(s) for a particular user.

Otherwise, you'll be copying orders from one table to the next whenver
a state change occurs and you'll also be doing joins over several
tables for some queries.

My $0.02,

dean

On 4/24/06, Campano, David <David_Campano@bcbst.com> wrote:
> - User B should only see orders with 'Submitted' status and can 'Approve'
> ----------------------
> order_id
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>


--
Dean Wampler
http://www.aspectprogramming.com
http://www.newaspects.com
http://www.contract4j.org
5d15c6821f3c3054c04b85471824ba7c?d=identicon&s=25 Kevin Olbrich (Guest)
on 2006-04-24 16:32
(Received via mailing list)
Since 'status' is probably a property of the order, I probably would not
create a separate class for it unless it was truly necessary.

it's not too hard to do

Order.find_all_by_status('Complete')

Then you only need one table

Orders
-- id
-- name
-- status

As for the rest, I'd take a look at the user/login engine combo as it
has some nice role based access control (there are others).

You can create a view/controller method for each of the 3 cases you
describe.
Most of the role bases access control systems will allow you to restrict
who can access which controller/action pair.


On Monday, April 24, 2006, at 10:16 AM, Campano, David wrote:
>- User C should only see 'Submitted and Approved' orders and can
>Name
>
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>


_Kevin
A90204c955db033cd975f7bb0ec9600b?d=identicon&s=25 Ashley Moran (Guest)
on 2006-04-24 18:27
(Received via mailing list)
On Monday 24 April 2006 15:29, Kevin Olbrich wrote:
> Since 'status' is probably a property of the order, I probably would not  
> create a separate class for it unless it was truly necessary.

Just to clarify what I say below, status might be a property of the
order, but
the name of that status isn't, hence it should go in a separate table.

> -- status
I would avoid this personally - it opens you up to inserting invalid
statuses
in the orders table, duplicates the status name which wastes space, and
means
if you ever want to change the description of a status, you have to
update
every order with that status.  Personally I don't think this strategy is
ever
worth the risk.

Ashley
5d15c6821f3c3054c04b85471824ba7c?d=identicon&s=25 Kevin Olbrich (Guest)
on 2006-04-24 18:42
(Received via mailing list)
I would suggest that over-complicating the problem carries it's own
risks.
While strictly speaking, you are correct, it is also not very hard to
deal with.

For example, what if someone accidentally deletes a record from your
'statuses' table?  Best case, it breaks things when the database can't
find the status id, and worst case, it deletes all the records with that
status (if you have your models set up wrong).

If you don't let the user type in the status directly, you can just use
global array with the values in it.  I presume that you won't be
creating a lot of new types of statuses as you go along.  In any case,
if you want to do it that way, then follow some of the other poster's
suggestions.

use
Order
  belongs_to :status
Status
  has_many :orders, :dependent=>:nullify

and make sure there is a status_id field in order.


On Monday, April 24, 2006, at 5:24 PM, Ashley Moran wrote:
>> it's not too hard to do
>I would avoid this personally - it opens you up to inserting invalid
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails


_Kevin
4daf0b71d5d9a3882e583c0e72eaf5dc?d=identicon&s=25 Alan Francis (Guest)
on 2006-04-25 12:45
Kevin Olbrich wrote:
> I would suggest that over-complicating the problem carries it's own
> risks.

I'd agree with that.  I'd leave the db with an integer status code, and
use composed_of to (in the words of Chad Fowler's Rails Receipes) make
dumb data smart.

If your db has a 'statuscode' column, and you'd like a 'status'
attribute which is an object, you could do:

class Order < ActiveRecord::Base
  composed_of :status,
              :class_name => 'Status',
              :mapping => [%w(statuscode status)]
end

Alan
This topic is locked and can not be replied to.