Storage of Repository data is pretty straight forward - every entry in its
transaction log can be a separate file, timestamped at the time of its creation
(preferably the proven time of persistence of the transaction log entry). But the
retrieval of data is a lot more complex.
This morning I finally arrived at the idea of how to efficiently and effectively
ensure repository Atomicity at query time.
As it stands right now, repositories are linked via @ManyToOne relationships. This
is easy to do since the Many side of the relationship contains the foreign key into
the parent table. However, as I've been writing the first internally provided DApps
I realized that there is a need for linking from the @OneToMany side as well. And
the proposed solution opens up the possibility of a Graph database implementation on
top of AIRport.
I've recently learned that some organizations value
working with raw SQL. Keeping your queries in
raw SQL makes sense and I am starting to design an
additional, SQL-first ORM for AIRport.
AIRport has a very useful feature: all objects passed into
@Api() methods get updated with the latest state (when
they are returned back to the Client). This is very
useful - the Client doesn't have to re-query the object
to get the latest state: less code to write and
maintain (and faster applications). However there are
cases where objects in the passed in object graph must
As I'm using AIRport APIs I'm realizing that the
existing records passed into AIRport APIs need to be
verified as such. This is leading me to finalize the
Id API for AIRport.
The Internet came together as a miracle, really. Anyone with a wire can publish, we need to keep it that way.Barry Diller
In 2015 I wrote a Family Organizer and realized that families would have to trust a company with their plans. I started to write a relational adapter for Google Docs to store data in personal accounts. Overtime it evolved into AIRport . I have been thinking that AIRport can also work in centralized environments and seamlessly serve both centralized and decentralized data. Now I'm realizing how siloed, centralized databases can join a fine-grained, privacy oriented network of virtually decentralized databases. ...
One thing I'm starting to think about is adoption of AIRport. It will certainly
be useful for building production applications but it's query syntax lacks a bit
when it comes to quickly cranking out prototypes.
Working with raw AIRport ids is cumbersome. The reason for that is the fact
that an Id of an entity is spread across 3 different entities:
A key factor in Turbase (and thus AIRport) adoption will be the ease of
writing applications. One key feature that needs to be done in a
developer friendly way is Dependency Injection.
A key feature of AIRport framework is the ability of applications to interoperate.
This is possible because of two reasons:
As the name states, Autonomous Interdependent Repositories are meant to be
interdependent. This basically means that records in one repository
can have columns with ids pointing to records in other repositories. In
itself its a simple concept however it presents a number of technical
issues when actually implemented.
Recently I got the inital implementation of application isolates working
(in browser only, without pulling application code from remote location)
and as part of that did a pass on API implementations.
Unlike JPA/Hibernate, AIRport entity management is sessionless. The way
it accomplishes change detection is via
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?
Schema migrations are hard in general. In AIRport/Turbase schema migrations
are even harder for a number of reasons:
In AIRport any given virtual repository can be in multiple states at the same time. This is because multiple users can be using the same virtual repository. Since they may be using a repository while being offline, the repository will get out of sync with the rest of the devices that have it. Hence, to keep track of that Turbase version controls all of virtual repositories using a simple Directed Acyclical Graph. ...
For a while now AIRport has been the brand for the AIR technology. And also for quite some time we've been dicussing building an adverisement engine on top of AIRport to generate revenue that can be shared with Apps and users. Now finally I've come up with a good enough of a brand for the actual App that will be installed on phones and other devices - Turbase. ...
I've now come to a full realization of what logic in isloates mean - locally-run vetted components. This trully changes the way AIRport applications can be written. Apps are no longer required to maintain expensive (to most people on the planet) server side components. Also that allows for a degree of independent developer specialization that is already standard among most professional programmers and UI designers. ...
Internally Airport used "on the stack", token based dependency injection to allow for seamless framework upgrades on each device. However this type of injection is non-standard and can throw schema developers off (as something unfamiliar and therefore unnatural). With introduction of isolates adding more tranditional constructor based dependency injection scheme becomes possible. ...
The next step after code execution isolates and schema upgrade strategy is defining exactly how schemas will be installed and how they will run. Here is my first (detailed) take on it. ...
Another issue that has been bugging me for quite some time is how exactly schema upgrades will work. My initial thoughts have been about building a framework that will enforce backwards compatibility for schemas. Switching to natural DAO logic lead me to re-think the approach and make it more natural, give more freedom to schema developers and define schema interoperability rules.
The solution to natural DAO logic
For quite a while now I've been dreading having to write Firebase-like rules for mutation logic. I have a number of reservations about writing a custom syntax engine:
4 month have passed since my last blog post and I didn't have any
time to devote to coding. Hence I'm open sourcing the projects
"as is" (with a bit of additional documentation).
I haven't head as much time as I have hoped to develop Highway
So during the beginning of this year I'm focusing on
developing a prototype product based on Highway and developing
Highway itself in the process.
Ability to support transactions has always been important with AIR
the API has been in flux until now. Here is the description of the
version of the API.
Quite a bit of code written as part of the Airport effort really
little to do with the concept of Autonomous Interdependent
Here is a list core, already working features...
Since the beginning of the Airport project the question of how to share data was outstanding. Eventually I started the automated-gateway-transit library to act as a gateway between airport instances...
Initial designs behind Airport called for an all-in-browser framework. However after I did enough research this proved to be impractical for the following reasons...