DBAccess: a Thread-safe, Efficient Alternative to Core Data

DBAccess is a new ORM for iOS that promises to improve on Apple's Core Data by providing thread-safety and high performance.

DBAccess claims to provide three key benefits over Core Data:

• Thread-safety.
• High performance and support for query performance fine tuning.
• Event model that enables binding data objects to UI controls and keep them updated with changes made in the database.

DBAccess can be used and distributed freely. Its latest version includes a few improvements such as support for ASYNC queries, better performance with large result sets, and reduction in memory usage in queries with many columns.

DBAccess proposes a very simple usage model. A persistent object declaration is very similar to a Core Data's:

    @interface Person : DBObject
 
    @property (strong) NSString* forename;
    @property (strong) NSString* surname;
    @property int age;
 
    @end

Creating, removing objects, or querying the database follow known patterns:

    Person* p = [Person new];
    p.forename = @"Adrian";
    p.surname = @"Herridge";
    p.age = 35;
 
    [p commit]; // save the object into the table
 
    [p remove]; // and now remove it

    DBResultSet* r = [[[[[Person query]
                             where:@"age > 30"]
                             limit:10]
                             orderBy:@"surname,forename"]
                     fetch];

InfoQ has reached out to DBAccess' author, Adrian Herridge to ask him a few questions.

What were the main reasons to write an alternative ORM to Core Data?

At the time I started the project iPresent was still part of its much larger software house Compsoft plc. Where on average 5 teams of devs would be churning out several apps at a time, some of which used Core Data for its persistence requirements.

Being an open and sharing environment, people were not shy about the problems with performance, threading and behaviours that they felt were missing and really should be there (such as joins and aggregation functions).

The main benefit for using Core Data was the GUI style of editing table and relationships, but then there were often problems with the editor making changes in the wrong version of the model, which often played havoc with our version control systems and at one point introduced a huge issue to one of our released applications with the addition of a field.

From my personal perspective I found it removed some of the core abilities of SQLite which I had been working with for 5 years prior, and had come to love its simple and exceptionally high performance interface.

So I felt highly restricted by the inability to use sub queries inline, joining tables to remove the need to nest some queries within loops, which often resulted in some very expensive routines. So at the time, it just felt like there were so many pitfalls to using Core Data with very few real world positives.

Given the mixture in abilities of the development teams, we often struggled with people not understating the syntax for the predicate queries and the introduction of extremely subtle bugs and crashes when slight mistakes were introduced with cross thread methods being called.

So, in summary, the main reasons for writing DBAccess were to improve on what myself and other developers felt was very poor performance for anything that required nested queries, alleviate frustrations of having to worry about threading issues, implement joins and subqueries.

How would you describe DBAccess strengths so that an iOS developer can make the choice of using it instead of Core Data?

• We tried to implement DBAccess so it was as natural to use for developers as possible, sticking with standard SQLite syntax wherever possible. So I guess point 1 would be that it is easy to use (at least people here and the few that have contacted me have thanked us for creating it, some even offering a donation which we had to politely refuse).
• The performance of DBAccess is also of great benefit, we have strived to ensure that we have profiled most of the codebase (currently approximately 15k lines), Core Data is fast enough if doing simple retrievals, but tends to suffer when committing data back into the database, and positively dies on it feet when it comes to nested queries., we try to optimise the writes and record caching wherever possible which we found made a huge difference to very “chatty” iOS applications.
• Simple, and quick to implement query objects. We hated the fact that in most applications it made it necessary to have a class that dealt with queries for the application. Sometimes this makes absolute sense, where you perform the same query over and over. But just from a readability and time perspective we wanted the FLUENT interface to be compact and easy to read, so being able to pull items out inline, within a for loop was very beneficial to the devs. e.g.

  for (Person* in [[[[Person query] where:@“age >= 18”] orderBy:@“age”] fetch])  {
  ...
  }
  

  .
• Implementation of COUNT, SUM, IDs, GROUP functions, which are performed at the SQL level and not after a heavy and memory consuming query.
• Completely thread safe, you can query and commit at any moment from any thread.
• DBAccess has an event model that allows you to register blocks of code to run when certain objects are updated anywhere else in the system, and also if any of the underlying tables are modified in anyway. This makes linking the data layer to the GUI simple and we have down all of the heavy lifting with handling threading issues and the async nature of these events.
• We implemented the ability for developers to specify which database file an object is stored in, so you could split your data layer across multiple files.
• Column based AES256 encryption. 8.A property/column can be any possible NSObject derived class that supports encoding using an NSKeyedArchiver, DBAccess then stores it as a BLOB and wraps it within its own storage type which contains all the information required to re-inflate the original item.

DBAccess is currently closed-source. Don't you think that this could hamper its adoption in the iOS community? Do you have any plans to open-source it?

Initially we planned for DBAccess to be an open source project, but there were significant complexities involved within my company that made this not feasible at that time. So I agreed that we would compile it as a closed source framework and distribute it as free to use.

I do agree that it could hamper its adoption in the wider community, but unfortunately it took a year to get agreement to distribute it closed source, and holding out for our initial target would have taken even longer to achieve.

We would hope to alleviate this with a really open licensing agreement, and possibly some guarantees about the kind of code that is contained within the framework to ease minds.

I am often in dilemma about open source projects and contributions towards them, I have witnessed many projects where well wishing developers have often added or demanded features and functions that detract from the initial plan or idea, this might become an issue with DBAccess currently being used in many projects at this moment in time (18 that we know about), we would need to make sure that changes to the project would not affect or detract from the methodology already employed in applications in development. So I am personally in favour of open source and developers contributing towards the project, but I have slight concerns about the additional work that managing the input and agreeing future development would have on our workload.

As only about one third of DBAccess is documented and released to the public at this moment in time (all is actually there, but it's not present in the header file and therefore no one knows about the extra features or functionality, including GUI object binding, data adapters, advanced relationships and a whole upgrade and migration schema system). I have recently sent developers who contact me extension packs to unlock or change the functionality of the framework. So in that respect, and one of the better features of objective-c, is that if developers want to contribute or customise they are easily able to add to the feature set by creating extensions and the core data storage and retrieval would remain the same.

I am certainly pushing and willing to release extensions to the framework as open source and downloadable from the website, and this could easily include contributions from the wider developer community. This would mean taking the currently un-documented features in DBAccess and turning them into open source components, but leaving the core framework closed for the reasons stated above.

As for plans to open source the core framework? I will continue to pursue this aim, but I can’t see it happening any time soon. Especially as there is no benefit to our company to release it entirely as an open source project.