Persistence Using Layers
Today you can use any Java based persistence API, where StrataCode can help you manage annotations, generate XML files, etc. You can break your models up into layers based on logical groupings of properties. Since you specify the meta-data per layer, you can use this organization to build one configuration which groups all fields in the same database, and another which groups them in separate databases. If the extend a shared layer, one or more overlapping properties could be used to seamlessly join from one to the other as needed. You can later move all fields defined in a layer into a different type of storage engine altogether.
There are several planned features to leverage layers with persistence:
Persistence with synchronization: the sync system can automatically persist objects on the server using a database or client using an offline store. Errors and conflicts can be reflected back for the application to resolve using error handlers and conflict resolution policies.
Use layers to provide a unified application programming model for data which is stored in different persistent stores - SQL, NoSQL, JSON in SQL. Code generation will generate a combined object which lazily pulls in from each data source, exposing the unified contract, doing joins as necessary directed by annotations or some code hooks.
Use layers to store changes to a record or set of records. A layer will store a set of changes made to an external data store, and present a view of the complete data store with the changes merged, while keeping modifications made in this separate layer. This is a powerful pattern that could be used to stage data changes to your content database. You can turn that layer on or off quickly to either see the changes or not. Run your tests so they are making changes in a temporary layer but in an environment where they can point to the production database for accuracy.
Use code-generation to make "plain java objects" work in a transactional way. They will use a shared, global cache for read-only operations. On the first change in a transaction for a given instance, we'll create a separate store for the changes. The getX method will consult this store before using the global cache so only the transaction will see the change until it's committed. We'll support various ways of synchronizing the global cache with a backend store. This architecture will perform much faster than using hibernate's or any other JPA implementation in a cached environment with a large graph of objects.