![](http://blogs.remobjects.com/blogs/media/blogs/mh/bugs.small.png)
The screenshot above shows something i’ve been working on as a side project in my spare time and as sort of a test case for the library work i’ve been doing on the OS X front.

What you’re looking at are two versions of my Bugs application, a native OS X client for the bug tracking database we use internally to keep track of – well, not just bugs, but pretty much everything that’s to be done, including support issues, management tasks, you name it.

Both applications leverage the RemObjects SDK for OS X that i’ve talked about before (and which is in beta now, make sure to apply!), but also a very early prototype of Data Abstract for OS X which – although the class structure is still very volatile an in the early design stages – is already working very well.

What’s great is that not only do the Mac and the iPhone version of Bugs rely on the virtually identical library code in RO and DA; even the application-specific data access code is all shared between the two, with the only core difference being the presentation layer (and the amount of actual data the app fetches). I originally set out and wrote Bugs for the Mac side, and when i finally made the plunge to get an iPhone version running, it took me literally a handful of lines of code to get the basic DA data showing. Pretty cool.

On the back-end side, we have a pretty complicated “legacy” configuration. We have no less than four separate Mantis databases that stores our data. The internal database structure used by Mantis is pretty… well… odd, so accessing this directly poses a few challenges. Eventually we’ll want to move away from Mantis entirely, but doing that means replicating a lot of functionality that isn’t there yet and that we rely on the Mantis fronted application for – not something done lightly.

So we have a middle-tier server done in Data Abstract for Delphi, which uses AnyDAC to access the four (ugly) MySQL databases that Mantis provides. It also uses ADO to talk to our MSSQL server to verify user logins (we use the same user db as our website for this, which will eventually allow us to easily open access for all out customers to access parts of this data, themselves).

The four MySQL databases are abstracted to a schema that looks more closely like what we’ll eventually want our bug database to look like (once we drop Mantis altogether). The server is also leveraging Data Abstract’s Unions and the upcoming “DA HET” (short for Heterogeneous) feature to make each of the tables appear (to the client) as one entity, even though data comes from four separate back end databases.

What DA HET does is it allows you to set different sources for individual data tables defined in your schema (including data tables that make up a combined Union, as done here), and expose them transparently to the middle tier and the client. Your code can simply work against a set of tables, without knowing or caring that data for table A might be coming from one database, table B from another, and C is actually merged from three different sources altogether.

Look for DA HET in a future release of Data Abstract, soon.

On the client side all of this is hidden, and my DA/OS X code just deals with single tables such as the “combined_bugs_table”, etc.
—
As mentioned before, DA/OS X is still very much a work in progress, but i do want to share a few code snippets to show how easy it is to access data from an existing DA server, already. This is code from a class shared by both versions of the Bugs app:

First, we create the standard set of components for RO/DA data access. For anyone who has used DA on Delphi or .NET before, the class names and concepts will be instantly familiar.

msg = [[ROBinMessage alloc] init]; channel = [[ROHTTPClientChannel alloc] initWithTargetUrl:@"http://..."]; dataService = [[RORemoteService alloc] initWithMessage:msg channel:channel serviceName:@"DataService"]; loginService = [[RORemoteService alloc] initWithMessage:msg channel:channel serviceName:@"LoginService"]; rda = [[DARemoteDataAdapter alloc] initWithDataService:dataService loginService:loginService];

Once we hold a RemoteDataAdater configured to access our server, we can fetch data – in this case we’re getting the full set of records for just one table – combined_bug_table (which, server-side, is the union of four distinct bug_tables from different database).

data = [rda getDataForTable:@"combined_bug_table"]; bin2 = [[DABin2DataStreamer alloc] initWithData:data forReadOnly:YES]; DADataTable *bugs = [bin2 getDataTable:@"combined_bug_table"];

The result is a DADataTable object that contains a recordset with the data. You can access this from code, accessing data by row and by field name or index, or use Cocoa Binding to bind it to user controls, such as the NSTableView or UITableView in the screenshots above.

Wanna know more about RemObjects SDK and Data Abstract for OS X? Drop me a mail or comment, or apply for the beta.

Enjoy!