Extract Mappers and Entities into separate repo

[paulstatezny]

Extract Mappers and Entities into separate repo

This is an exploratory, "for discussion" issue. The vision for why this may be a good idea can be summed up in a list of pros and cons.

Pros:

• Changes in the abstract mapper/entity/data-object do not require new releases of Synapse Base.
• Community members might actually be interested in this as a lightweight database abstraction layer. (More dev community visibility for Synapse.)
• It is perhaps the only "fully-featured" abstraction in Synapse Base that could logically exist as its own library. Extracting it would make synapse-base more cohesive. It's meant to be a project bootstrapper, not a library in and of itself.
• Improvements in the Mapper/Entity abstraction could be immediately used in projects without having to update Synapse base. (e.g. Synapse Base master could use MapperAbstraction v1.0, but the Project could separately require MapperAbstraction v1.1 and the latest Synapse Base.)

Cons:

• "Another repo to manage."

Acceptance Criteria

1. Mappers, Entities, and the base Data Object are extracted into their own repo.
2. synapse-base requires them via composer.

Tasks

• Remove classes/traits and tests from this repo.
• Create separate repo for it.

Additional Notes

• Any discussion is encouraged! Drop a note, leave a criticism.

[paulstatezny]

1️⃣ ⬇️ ☀️

[zpchavez]

Shouldn't this have the F-Version 2 label? ⭕

[zpchavez]

Where will MapperTestCase live? Seems like it would be useful to have it be part of the mapper repo.

[zpchavez]

But that might be a problem, since MapperTestCase extends AbstractSecurityAwareTestCase.

[baohx2000]

As long as the mapper package also depends on synapse-base that shouldn't be an issue. The idea is the mapper package can optionally be used with synapse-base, but not by itself. In other words, we could use a completely different DAL in synapse-base and not have any mapper stuff in the codebase.