First of all, I'm doing this project for a friend that helped in the past and to get some feeling with ROR. I will tell you some more about the use case to get a better insight. So please bare with me...
This friends acts like a mediator between sales agents and a bank or insurance company. For every product that he offers, he has a tree where each node is a sales agent. The tree is not that big but I still use the better nested set plugin from Krishna Dole with a scope on the column product_id wich is a FK. Ofcourse a sales agent can write more than one proposal. As mentioned earlier, there are three different stages that have to completed before a sales agent can get a commission (simplified):
1) He writes a proposal of a product for a client
2) The mediator sends the proposal to the bank or insurance company and they approve it by issuing a policy for the proposal with a number and date
3) The client pays the initial fee in a certain month and the policy becomes a real contract. For example: the client is now insured against fire for his appartment. The mediator gets a commission and he distributes the bigger par to the sales agent who wrote the initial proposal and a small part to the ancestors up the three.
This little project is all about generating a monthly sales report for each sales agent.
The three models Proposal, Policy and Contract are not that different for now because I want to keep things as simple as possible to start. But it is important that a contract can be revoked because the client stopped payment and effectively changes back to a policy. This is important because the bank or insurance company will ask their money back. The mediator ofcourse has to ask a part of the commission back from some of his sales agents. This doesn't happen that often but it's important to have a good model that can keep track of this. So a contract can go back to a policy and a policy can become a contract again.
For now, I have a table proposals that looks like this (for now, this is sufficient):
CREATE TABLE `proposals` (
`id` mediumint(8) unsigned NOT NULL auto_increment,
`client_surname` varchar(64) NOT NULL,
`client_firstname` varchar(64) NOT NULL,
`postal_code` NOT NULL,
`city` varchar(128)NOT NULL,
`agent_id` mediumint(8) unsigned NOT NULL,
`written_on` date NOT NULL,
`units` smallint(4) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `FK_AGENT` (`agent_id`),
CONSTRAINT `FK_AGENT` FOREIGN KEY (`agent_id`) REFERENCES `agents` (`id`) ON DELETE SET NULL ON UPDATE SET NULL
If I would use STI for this simple case, then I would just add the following columns to represent a Policy and a Contract:
type varchar(32) NOT NULL, <- STI type
policy_number mediumint(8) unsigned,
first_payment_on date <-- Contract
The behavior of the three classes is not really important. It's just important to display proposals, policies or contracts seperately in the view together with the extra attributes for a proposal or contract.
But it's all about the state changes between a Contract and a Proposal. Because if it happened then it will show up in the final sales report.
I'm thinking about adding a FK to a table called states for the current state and a FK in the states table back to the proposals table to have a history. But then again, how can I keep the current state consistent with the class? Here I'm lost again because different states have different attributes. This would mean that I would also have a STI for the states table.
I would be happy for now if I just can make the transitions from proposal to policy and then contract. Should I hack the type column to avoid destroying a proposal and creating a policy with the same attributes plus the two extra ones?
I've went through the slides and I must say that for now I don't do use the RESTAPI yet.
Thanks for your reply,