Revised MVP

[jvjohnson1]

If Paula agrees, I'm pushing everything that requires a Duties table to Version 2. Duties is complicated not only because it's many-to-many and requires an Assignments table for joining, the same duty can be assigned to the same soldier more than once (repeated tasks on different dates). This is not compatible with using SoldierID and DutyNumber as a composite key in Assignments, because it would not be unique. In a simple database project I could do it by giving Assignments an independent primary key (assignmentNumber) and making SoldierID and DutyNumber foreign keys. That makes the Java and Hibernate a bit too much at this point. The database tables left in MVP are Soldier ( a parent class, but concrete) Officer (a child class of Soldier but in a separate SQL table) and Platoon, which has a one-to-one relationship with Officer and a one-to-many relationship with Soldier.
With only one company simulated, Company is not an entity itself but the database as a whole. The Captain is an Officer, but is not a member of any platoon.

[pawaitemadisoncollege]

I am ok with moving Duties to V2. You will still hit the requirement for multiple one-to-many relationships with the Solider (user) and Role table, and Solider and Platoon table.

As I mentioned several times, there is no need for the Officer table. The Role table and Soldier table will cover that scenario easily. Creating an additional table for Officer will add an unnecessary level of complexity to your application and likely more frustration for you. If really want to experiment with splitting the Officer out, I'd recommend doing that refactor in V2.

[jvjohnson1]

Ok, makes sense if it works, I'll work on the Role table after brunch. I'm still not sure how we are going to secure some methods, though. A Lieutenant should only be able to view soldiers in his/her platoon (unless privilege escalation is successful, and script kiddies will certainly try.) Only privates can be modified in any way - changes to an officer's data would come from higher rank then I'm including in a small sample. One of the key elements is the separation of duties required for the delete method, and not just any lieutenant can second the captain - it has to be the commanding officer of the private being dismissed.

[pawaitemadisoncollege]

Role-based security is in week 7! The ability of a user to only access their own data is what almost everyone's indie project needs to accomplish - you are all doing this very similar work! Tomcat Auth (week 7) and Hibernate (week 4 and 5) are the pieces to make this work.

[jvjohnson1]

So the role table isn't covered until week 7, and I'm desperately trying to finish week 5, almost a month late. The Fortress doesn't have a business requirement for a simple one-to-many relationship. The role table introduces content not covered in week 5, and I want to at least follow the progression of the videos! Both duties and platoons are simple enough is sql ( I think I've written more sql scripts in the past year than you have, and more tables than we are even talking about here.) Yet the Java and Hibernate involved in duties (many-to-many and the same combination of foreign keys can repeat in the case of recurring tasks) and platoons (one-to-one relationship with officers and one-to-many relationship with privates, when you recommend keeping officers and privates in one Soldier table) is more complex then the examples and you advised me to move on to roles.
You (and Heather) so concern when I get so distressed by being late, but in security late is measured in nanoseconds. For perspective, light can reach the moon is about 1.5 seconds, while in a nanosecond light travels about three meters. Only a computer can respond that fast, but a computer can. In the duration of a processor cycle, light travels 17 centimeters, so one nanosecond gives you at least 17 cycles. Obviously you have to use Assembler, because the Java Virtual Machine introduces some overhead you can't tolerate when an attack is coming at lightspeed from only a few yards away. If I have this much trouble with Java, how will I ever master Assembler?

[pawaitemadisoncollege]

All you need to know about the role table right now is the structure which is listed in slack #indie-project. It's a very simple table and should make the week 5 work as easy as possible. I specifically posted the role table structure on 9/30 so that students could add that table in week 5 and save themselves some time!

[jvjohnson1]

Back to things that work in human-perceptible spans of time, the role table structure you showed does not include a hashset, or any kind of collection, who what gets the @one-to-many annotation?