Generalize interface to databases

[pylipp]

In the current implementation, a single interface to tinydb exists: financeager.periods.TinyDbPeriod. For adding different interfaces (e.g. for sqlite, Postgres), the base class should

• have abstract methods add_entry, remove_entry, update_entry, get_entry, get_entries
• provide the methods for validating and preprocessing input

[cardinalion]

Is this how you write a class with abstract methods?

class DBPeriod(Period, ABC):
    def __init__(self, name=None):
        super.__init__(name=name)
    
    @abstractmethod
    def add_entry(self, table_name=None, **kwargs):
        pass
    @abstractmethod
    def remove_entry(self, eid, table_name=None):
        pass
    @abstractmethod
    def update_entry(self, eid, table_name=None, **kwargs):
        pass
    @abstractmethod
    def get_entry(self, eid, table_name=None):
        pass
    @abstractmethod
    def get_entries(self, filters=None):
        pass

class TinyDbPeriod(DBPeriod):
        pass```

[pylipp]

Yes, exactly! I'd suggest two more things:

• derive the existing Period class from ABC, instead of introducing a new DBPeriod class
• provide docstrings ("""Explanation of parameters, functionality, and return values""") instead of passes for the abstract methods. You can move parts of the docstrings of the existing TinyDbPeriod methods.

[cardinalion]

That would be better. I understand the first thing. As for the second, I feel like I can't just copy and paste. What would be difference between the docstrings of Period class and the docstrings of TinyDbPeriod.

[pylipp]

If the docstring contain a detail that is specific to the tinydb implementation, this detail should remain in the TinyDbPeriod. The general parts can go into Period.

[cardinalion]

That makes sense

[pylipp]

Did you install the dev tools as described in the section Contributing of the README? This way, formatting of the commit content and the commit message is automatically taken care of.