Purpose:
This platform is growing in complexity and already utilized a handful of factory objects. However, there's some awkwardness with how we use or pass the factory objects around. I'd like to integrate dependency injection to help with automating/managing this better.

The app is currently tightly coupled with Google Firebase Auth for user access. I don't like this coupling (what if firebase auth goes away). I'd like to migrate the authentication of our application to a pydas_auth module that can allow for the user to select and configure the auth on their own. We can utilize the before_request function to then engage with the auth module and validate user rights.

This is dependent on #13.

Once all extensions have been removed, many sub-packages may be reduced down into modules. An example of this could be the transformers package. Once the IEX extensions have been removed, they can be reduced down into a transformers module with the Transformer class and a couple of utility functions.

There are others that may not be reducible yet, such as the formatters. However, this will be a case-by-case determination.

This will result in breaking changes to the API, as some code may rely on the sub-package architectures.

Reading through SQLAlchemy session documentation it was suggested to keep sessions external and separate. It was also suggested that the sessions are carefully transacted (commit on success and rollback on exception). Currently, pyDAS does neither of these.

• Investigate using dependency-injector to inject session contexts
• Create a context manager as shown via example in the article linked above

Doing both of these should help with better session management and handling errors.

This codebase is cluttered with extensions that are not generally useful. This causes bloat in the codebase and bloat in the dependencies. To reduce this bloat, and move this project towards a more generally useful state, these extensions should be moved.

The eventual landing place will be the pyDAS-Extensions repository.

This is dependant on #13.

Once we've removed all extensions from the codebase, we'll further clean the codebase by removing the Base prefix on all abstract classes. This will be a breaking change that affects all extensions.

The install docs haven't been updated in a long time, they need to be updated to address changes to the new pydas.yaml config, pending updates to the installer, and how to properly install the pyDAS system (via pip) with required extras.

For new database installations, the foreign key constraints on the optionsbase table is set up wrong. It sets up two FK constraints, and sets UPDATE and DELETE events to restrict instead of cascade. This is a problem because the constraints conflict with the companyfeaturebase table. If there's a deletion, then the user will get a key violation error.

We need to properly configure the foreign key on optionbase to map to both columns, and cascade delete/update actions.

The pyDAS.install module was created before we consolidated our configuration into one YAML. It also lacked functionality into creating a uWSGI configuration script. The former issue causes the GitHub workflow step to run the install script to fail, and has subsequently been disabled.

We should fix the script to:

• Use the consolidated configuration script
• (Optional) Support manually configuring the script via CLI arguments.
• Configure the uWSGI config options (consider either creating a new INI file, or adding a uwsgi section to our pydas.yaml)
• Deploy a new database (especially for SQLite) if required.

What are you trying to do?

Currently, the option model is only supported for feature. However, this quickly becomes a pain when adding the same option to many features on a company. I'd like to change this to support company-wide or feature-wide overrides (such as adding a range modifier on all features mapped to a company).

There's a couple of options that thought about:

1. Create additional tables for feature options and company options.
2. Alter the existing option table to add a discriminator column to specify what type of option:
   a. company (global)
   b. feature (global)
   c. company-feature

I would prefer the latter option, as it's a smaller change, and SQL Alchemy supports model inheritance using a discriminator. The following image shows what this setup might look like: