Decouple DB model from logic

[Glutexo]

Persisting hosts into a database is a form of serialization. The Host model’s responsibility is to represent the database record. It shouldn’t on the other hand

1. contain any logic – instantiation, operations, export
2. represent a host in the application

This can be done in separate steps:

• Extract the export method to independent exporter functions/objects. Extract (de)serialization methods #326
  • to_json
  • to_system_profile_json
• Extract the constructor methods to independent importer functions/objects.
  • __init__
  • from_json
• Extract the action methods to a logic module or to a app (non-db) model class.
  • update
  • patch, _update_ansible_host
  • update_display_name
  • update_canonical_facts
  • update_facts
  • replace_facts_in_namespace
  • merge_facts_in_namespace
  • update_system_profile
• Remove the database operation related method.
  • save

The logic of how the fields and values are updated are in no way related to the database storage. Decoupling allows the application to operate with a simple object representing a Host instead of a database model with a lot of added behavior. The database model would be used only for the storage/retrieval. This increases predictability of the application.

[Glutexo]

Currently working on decoupling the export methods.

[Glutexo]

Adding that currently storing data to the database is also a kind of serialization. Splitting the database model (a SQLAlchemy object) from a business logic representation would allow to internally store the data in a smarter way. E.g. to use a namedtuple for canonical facts and a defaultdict for facts.