macOS Database programming in Cocoa

[MacRohde]

I'm trying to get started in Cocoa/Objectiv-C (I program in C#/.NET at my day job) and I need to access some databases, but I can't seem to find any info on how to use Cocoa for data access.

I've browsed the docs for Core Data but at the moment that's overkill, also the fact that I can't use MySQL is a no go, so it seems I have to use the C API that comes with MySQL - is that so?

 

[garethlewis2]

In one word. Yes.

In more words, you need to write a wrapper around the MySQL C API. It isn't difficult. All you will need is a basic class that opens a connection, closes a connection, executes a query as both a proper query with a result batch and as a simple update, delete or insert.

 

[aaronbrethorst]

I'm trying to get started in Cocoa/Objectiv-C (I program in C#/.NET at my day job) and I need to access some databases, but I can't seem to find any info on how to use Cocoa for data access.

I've browsed the docs for Core Data but at the moment that's overkill, also the fact that I can't use MySQL is a no go, so it seems I have to use the C API that comes with MySQL - is that so?

You might want to check out the MySQL-Cocoa framework, although I've never actually tried using it, so your MMV. Good luck

 

[garethlewis2]

Ha ha.

That's so old, it isn't even being maintained anymore.

 

[Eraserhead]

You can use CoreData with SQL, and its really easy to program.

 

[MacRohde]

Thanks for the replies, guys

 

[DaveGee]

You can use CoreData with SQL, and its really easy to program.

Yea but isn't that limited to SQLite? Last I head if you need to connect to remote databases and lets face it many/most/all true DB developers do... CD would be a dead end...

So, sure if you want to take advantage of SQLite (no network connections) in a standalone app CD is great but after that it falls down quite rapidly... I sure hope this changes with Leopard!

Dave

 

[Eraserhead]

Yea but isn't that limited to SQLite? Last I head if you need to connect to remote databases and lets face it many/most/all true DB developers do... CD would be a dead end...

So, sure if you want to take advantage of SQLite (no network connections) in a standalone app CD is great but after that it falls down quite rapidly... I sure hope this changes with Leopard!

Dave

It seems you are correct. It's local only for now, but remote (hopefully) is coming later, good that'll be useful for my application then!

 

[SC68Cal]

In one word. Yes.

In more words, you need to write a wrapper around the MySQL C API. It isn't difficult. All you will need is a basic class that opens a connection, closes a connection, executes a query as both a proper query with a result batch and as a simple update, delete or insert.

This sounds like the best idea so far. Complicated, yes, but if you're using MySQL, you're not going to settle for SQLite.

 

[MacRohde]

This sounds like the best idea so far. Complicated, yes, but if you're using MySQL, you're not going to settle for SQLite.

Yes, and it might even be fun to do such a wrapepr - although it does take some time. Core Data seems nice and it would be pretty great if remote acces is added to the framework.

 

[SC68Cal]

Yes, and it might even be fun to do such a wrapepr - although it does take some time. Core Data seems nice and it would be pretty great if remote acces is added to the framework.

See, that's a big if.

I'm not very familiar with SQLite, since I work as part of an in-house dev team where we have certain luxuries (such as our own servers) so we like to use MySQL so that we don't have to worry about regular users mucking around with the database.

My general feeling is that you're opening a whole can of worms when you basically give Core Data the abilitiy to communicate with remote hosts. I imagine that since Core Data is part of the system, and there is the possibility that there are plenty of Carbon developers working on it, I don't really know if I'd want to give Core Data the ability to listen and transmit over the network, as a "standard feature" that is turned on when most people won't use it. Too much can go wrong, you know?

I've looked over the Cocoa-MySQL and worst case, you could probably take a look at what they've done and maybe clean up their shop a bit, with whatever you end up doing, then submit it back to them. I'm sure they wouldn't mind.

Good luck, either way. I know one of these days I'm going to start learning Cocoa, it's just that I have to wait for the job to get enough OS X machines to justify the time.

 

[MongoTheGeek]

Yes, and it might even be fun to do such a wrapepr - although it does take some time. Core Data seems nice and it would be pretty great if remote acces is added to the framework.

I was so hoping to see that added to CoreData at WWDC. Its not like they don't ship MySQL with OSX anyway.

 

[garethlewis2]

Even if they did add this type of access to CoreData, you wouldn't want to use unless you were writing the noddiest of programs. For anything remotely complex, you would want all the database access controlled by a single server object. All screens, controllers, etc would simply ask this server to execute a query on the database, and this server would handle the task of processing the results. It is also a better design as you could easily scale the application to run across several machines using NSDistributedObject, CoreData unless it becomes an actual service that can run from remote machines rather than locally is going to limit you to writing an application that can only run on a single machine, with multiple processors mind-you, but it is very very limiting.

 

[Krevnik]

Even if they did add this type of access to CoreData, you wouldn't want to use unless you were writing the noddiest of programs. For anything remotely complex, you would want all the database access controlled by a single server object. All screens, controllers, etc would simply ask this server to execute a query on the database, and this server would handle the task of processing the results. It is also a better design as you could easily scale the application to run across several machines using NSDistributedObject, CoreData unless it becomes an actual service that can run from remote machines rather than locally is going to limit you to writing an application that can only run on a single machine, with multiple processors mind-you, but it is very very limiting.

Apparently custom data stores will be allowed in 10.5, but I really don't know what is expected in terms of what the data store provides to CoreData. If it lets you grab the fetch predicates and translate them to pass onto SQL, it would probably work just fine. If it requires that it handles fetches above you... then you are still right.