launchpad development
Persistence Layer
Launchpad suffers greatly by having no simple persistence layer. It has sql layer (Storm) but its regular business logic is intermingled with storage : we cannot test business logic without exercising the storage layer, we cannot test the storage layer without mixing in business logic tests, we cannot migrate components of our model to different storage systems (because of the intermingling). Performance suffers - there is no differentiation between object access and data retrieval, so any failure to preload data results in thousands of backend queries. And our test performance suffers because we're exercising the full stack every time we do anything. Lastly our business logic and storage logic have to change in lockstep because there is no separation between them.
As a Technical Architect
I want a real persistence layer
so that writing fast code, testing and evolution of our schema are easier to do than today.
This is not an ORM nor a separately library.
Rationale
Why are we doing this now?
What value does this give our users? Which users?
Stakeholders
Who really cares about this feature? When did you last talk to them?
Constraints and Requirements
Must
What MUST the new behaviour provide?
Nice to have
Must not
What MUST it not do?
Subfeatures
Other LaunchpadEnhancementProposals that form a part of this one.
Workflows
What are the workflows for this feature? Even a short list can help you and others understand the scope of the change. Provide mockups for each workflow.
You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.
Success
Bugs are at: Bugs for this LEP link to a search for a bug tag or milestone. Use launchpad-project rather than a sub-project.
How will we know when we are done?
How will we measure how well we have done?
Thoughts?
Put everything else here. Better out than in.
