with National Ignition Facility has achieved Q 0.7 - 70% break even on power output with lasers.
Everything as Repository
Unlike JPA/Hibernate, AIRport entity management is sessionless. The way
it accomplishes change detection is via
original values
tracking in a hidden object property. Recently I've been debugging
Insert vs Update detection and realized that everything is easier with
Ids that are generated. If the Id is present in the input it cannot
be an Insert. That got me thinking - should all entities be forced
to have generated Ids?
Another thing this decoupling of code from data does is that it allows entities other than publishers of the code provide different seed data. This helps a lot of the application is a data driven, generic piece of logic, meant to be customized/skinned based on different data that users (or publishers of other apps) can provide.
Even the original maintenance-data repository can be allowed to be modified and enhanced by users or can be published with read-only public facing permissions, or can be completely hidden from the rest of the world (other than the application itself). But more on that once the repository code is actually finished...
The new way is to just to disallow NON NULL columns for everything except record ids. This is also a form of denormalization but at least it doesn't compromise relationship integrity. What it does do is allow for is create stub records in the database, to keep track of missing repository records. This is because such records can exist with nothing but Id columns filled out (because all other columns are NULL).
This can be taken a step further with in-code maintenance of NON NULL constraints. That way NON NULL can still exist (virtually) for normal data and will simply be ignored for stub records.
Repository Entities - always generated Ids
Well, repository entities already have generated repository + Actor specific repository Ids (each AIRport database acts as a unique actor for a repository and hence it's auto-generated sequences are guaranteed to be unique in a given repository for that Actor/database). Hence, my next natural thought was - can all data in the database be in repositories?"Non-repository" data
Prior thought was that there was bound to be maintenance data that wouldn't be tracked in user repositories and bundled with the schema instead. Existance of such data is almost a certaintly. Examples of such data are dropdown values, and other lookup data.Everything is better in Repositories
Putting such data into repositories still works. In fact it makes maintainance of such data much easier. Now data-only patches are as easy as modifying data in the one of these publisher controlled repositories.Another thing this decoupling of code from data does is that it allows entities other than publishers of the code provide different seed data. This helps a lot of the application is a data driven, generic piece of logic, meant to be customized/skinned based on different data that users (or publishers of other apps) can provide.
Even the original maintenance-data repository can be allowed to be modified and enhanced by users or can be published with read-only public facing permissions, or can be completely hidden from the rest of the world (other than the application itself). But more on that once the repository code is actually finished...
Technical details
Another piece of information that hasn't been fully thought out until now is how exactly will Repositories with references to other Repositories exist in the database if the referenced repositories are not yet present in the database. The original thought was to disable all foreign key constraints on all tables and just have dangling references to non-existing records. However this suffers from schema denormalization since relations are no longer enforced.The new way is to just to disallow NON NULL columns for everything except record ids. This is also a form of denormalization but at least it doesn't compromise relationship integrity. What it does do is allow for is create stub records in the database, to keep track of missing repository records. This is because such records can exist with nothing but Id columns filled out (because all other columns are NULL).
This can be taken a step further with in-code maintenance of NON NULL constraints. That way NON NULL can still exist (virtually) for normal data and will simply be ignored for stub records.