Dismantling our classes

[gordon-cs]

Dismantling our classes

[eanyanwu]

GOAL:

• Come up with a clean and simple way to represent:
  • The concept of a common area rci.
  • A returning's student rci
  • A new student's rci that has been pre-filled by the RA, but might not yet reflect the room components the resident actually chose.

[eanyanwu]

Proposed DB Schema:

• RCI:
  • RCIID
  • Current
  • CreationDate
  • BuildingCode
  • RoomNumber
  • GordonID (Can be null)
• RCIComponent:
  • RCIComponentID
  • RCIComponentName
  • RCIID
• Damage:
  • DamageID
  • DamageDescription (Can be null)
  • DamageImage (Can be null)
  • DamageType
  • RCIComponentID

[eanyanwu]

Explanation:
RCI:
I've dropped the concept of a "ResidentRCI" and "RoomRCI" in favor of that of a simple RCI.
If a record in the RCI table doesn't have a gordon_id, it is for a common area. If a record in the RCI table has a gordon_id, it is for a person.
I added a CreationDate column to indicate when the rci was created. This is to help distinguish this year's rci from last year's.
Current is a boolean, which gets set to False upon Checkout.

RCIComponent:
This table no longer has a "RoomRCI" column. An RCIComponent record is associated with one rci. This is actually sufficient to cover the representation of the three goals I outlined.

Damage:
Two added colums. DamageImage which will be a path to where the picture of the file is stored on the file system. DamageType to help quickly tell if we should expect the damage to be an image or text description.

[eanyanwu]

Scenarios:
These are to prove to myself that the above representation works.

Assumptions:

• Residents create their rci. The system doesn't populate them before hand.
• In terms of the UI, you can create two types of rcis; a personal one, and a common area one. Both create the same type of record in the rci table, except that in the case of the common are, the rci record has no gordon id.

Common Area RCI:
Resident creates a common area rci for an apartment.
Other members of the apartment can access that rci because the system has a record of room assignments and can seee that they are part of that apartment.

Pre-filling:
RA creates and fills out rci for both new students based on initial assumptions on what furniture residents will choose.
To make the furniture the residents actually choose match up with what the system has, we provide an interface for the ra to reassign components to a different rci. In the database, this simply means changing the RCIID value for an RCIComponent.
The hard thing in this scenario is making an intuitive interface for this to happen. Database-wise, making the change is easy.

[superpowers11]

I like the simplification here! Nice work.
Trying to make sure I understand though - can an RCIComponent exist with a null value for RCIId? Like, before the components have been assigned to a specific RCI? Or would the system just automatically assign it to some RCI, and then if a change needs to be made regarding which RCI it belongs to, that's fine?

[eanyanwu]

Yup, the RA will just have to assign it to one of the RCIs. Later, once the ra finds out the actual furniture partitioning, he/she can then reassign components to the correct rci.

[superpowers11]

So the RA has to assign components to a certain RCI manually? Or the system will automatically assign components, to minimize RA work?

[eanyanwu]

Database schema has been changed accordingly.