List of Projects OSRA - Support system Technical discussions Modelling real-world objects in the OSRA application

Modelling real-world objects in the OSRA application

Updated about 5 years ago by Nikita Avvakumov
OSRA has models for Provinces, Statuses & SponsorTypes, among others. The db is seeded with 14 provinces, 4 statuses & 2 sponsor types.

Provinces:
14 province seeds represent 13 Syrian provinces + “Outside of Syria”. Each province object has a ‘name' attribute, which corresponds to the real-world province name, plus a ‘code’ attribute representing the province’s code in the current OSRA system. Both the names and the codes of seeded provinces are highly unlikely to change.

Treating provinces as regular db records necessitates the following validations:
  • name is one of the 14 valid names and is unique
  • code is one of the 14 valid codes and is unique
  • name matches code
While OSRA may expand its activity in the future to outside of Syria; or decide to subdivide some provinces into smaller regions, does this eventuality need to be taken into account at present? Such drastic changes in its operations will probably need to be accompanied by a substantial redesign of the application, which seems to be beyond the scope of the current effort.

In light of this, one solution is to 1) make the Provinces table read-only, so that no changes or new entries can be made by the client (presumably, the client would only try to do so unintentionally). The existing entries can be validated as described above merely as a precaution. 

2) A slightly less restrictive alternative is to prevent modification of existing records, but to allow addition (and modification?) of new ones. Finally, 3) the table can also have full read/write access. In these latter two cases, both names and codes cannot be limited by a validation to the current subsets of 14. However, the validation matching the 14 existing names to their codes should be implemented, and the uniqueness validations must remain.

A related, but somewhat separate issue is the modelling of provinces in tests. In province_spec.rb, Province.new or a factory can be used and tested for the necessary validations. Another point to consider, however, is that other models may have associations with provinces - only the Partner model at present but possibly others in the future. How to construct a Partner’s associated province? 1) Use Province.new/create with valid attributes; 2) Use a province factory; 3) Seed the test db with the same data as dev db and pull a record from it. 

Additionally, regarding #2 above: What kind of a province object should the factory construct? If it is limited to the existing 14 valid provinces, then there is a (very unlikely) danger that tests will break if more than 14 provinces need to be instantiated. Alternatively, if addition of new provinces is allowed by the application, the factory could make valid provinces that are not one of the 14 - i.e. they have unique names and codes that do not overlap with the existing ones. Finally, regardless of the overall solution for handling provinces, a factory can be used to make province objects that are technically invalid but have sufficient functionality to act as associations - e.g. names are a sequence of “a”, “b”, “c”,… and codes are a sequence of 1, 2, 3… We would have to be careful not to use such a factory in the model spec for Province.

Statuses and Sponsor Types have fewer constraints than Provinces.

Proposed implementation:

Having thought about all of the above, and having tested several of the solutions discussed above, I lean towards the following:

The Provinces table can be either fully open, or open only to insertion (and modification?) of new records. Existing 14 provinces should be validated for the name/code match, but entries whose name is not one of the 14 are free from that validation - they can have any name and code, as long as they are unique. Since addition of new records will be allowed, we need to remove the existing requirement that a province code must be one of the 14 current values.

The test database should not be seeded: touching the db introduces substantial overhead to tests, and in my experience using db records has led to fragile and not entirely transparent tests. Instead, we revert to using a Province factory that produces valid province objects whose names and codes are distinct from the existing 14. These factory objects can then be used both in the Province model spec and in other specs as associations.


Revisions

comments powered by Disqus