When building AutoDB I wanted something that was as fast as possible, avoided all the extra work/chores and problems other frameworks had but still didn't compromise on power and features. It also had to be automatic... Apple's CoreData is not thread safe, and that was my main problem. I never understood the reasoning behind this, but if you wanted to populate your GUI with info from CoreData you first had to fetch the data in a background-thread and then fetch it again in the main, GUI, thread. This is such an inconvenience and if you do something wrong, the app will crash, corrupt the data, and in the worst case the app itself will refuse to ever launch again! This is such a terrible design, I can't understand why people put up with it, and I didn't - so had to build something better.

I wanted the data to be accessible from all threads, as regular objects. There is no point in having strange thread boundaries, it only complicates things. Additionally, having regular objects have the benefit of making uniqueness easy. I decided early on to always use a 64bit int as an id, so when fetching from disk I can easily determine if an object is already fetched and exist in memory or not. The system keeps one list per class with weak references, its fast and easy to check if an object exists or not. Then it can be freely used by any thread in the whole app. This removes a lot of pointless complexity like determining what changes are the "true" changes. Imagine that you have two different views in your app, loaded at the same time exposing the same object. Both change the object - and later saves the changes to disk. What should happen? In CoreData you need to build specific code to handle this case, since those two objects are different but are stored on the same place on disk. In AutoDB they are the same object so if you change one parameter in view A, and another in view B, both changes are already visible in both locations. There are no conflicts and only one save-operation is carried out when saving to disk.

Another unnecessary hassle is migration. When you add properties to your classes, the tables need to update accordingly. In CoreData you need to manually perform a weird migration which is loading all data into memory, then saving them to disk using the new format. AutoDB just updates the table in-place and leaves you alone. Only when modifying the type of a column, will AutoDB need your manual help, since it can't know for sure how you like to transform a string into a date. Adding and removing columns and tables are also super-fast operations, even with heavy usage you won't notice the delay.

Automatic, so what does that mean? It means that if your data classes inherit AutoModel all of this comes for free.

This is all I will write about AutoDB this year. It is available here: https://github.com/AutoDB/autoDB. It was nice to get these thoughts down, have a good day! 😄