Re: mysql question
Re: mysql question
- Subject: Re: mysql question
- From: Simon Stapleton <email@hidden>
- Date: Sat, 20 Sep 2003 18:18:30 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Serge Cohen <email@hidden> wrote :
Hi Dan;
<snippage>
At last, concerning the difficulty of using the C API of MySQL... there
is already a Cocoa based framework which wraps the C API, you can find
it here :
http://mysql-cocoa.sourceforge.net/ (of which I'm the maintainer). You
can make it an embedded framework so that it is used while being
included in your application bundle (so that the client part of MySQL
is directly installed together with your application, avoiding that the
user as to do more than just copy the application).
This is all good advice, and mysql-cocoa is a rather handy little
framework if you need to use MySQL directly from within Cocoa. Thanks,
Serge, good work.
<more snippage>
PS: As the author/maintainer of MySQL wrapper for Cocoa I'm obviously
biased...
Heh. Here's my own, otherly biased, view:
First off, and IMHO, this is a rather more generic question than simply
'how do I use MySQL in my application' - after all, the OP wrote:
I'm wondering if anyone has any reasons for a Cocoa program not to
make use of MySQL (or PostgreSQL).
In answer to the OP's question, first, NO. If you need database
access, then there are no compelling reasons not to use a 'real'
database to do it. Doing so might make distribution of your
application somewhat more tricky, but what you want is functionality as
opposed to ease of distribution - the distribution part is another
problem to solve.
Choice of database platform is largely up to the developer. There is
no 'built in' database software available on OSX apart from .dbm
format, so the choice is pretty much open. There are many database
platforms out there, ranging from the simple 'use an NSDictionary'
approach to Oracle, and even the possibilty of using a TCP link to a
mainframe running something _really_ hefty. Personally, I use
PostgreSQL, but that's personal preference. Database choice, like
programming languauge and editor choice, can be a religious issue.
Pick what works best for you, and stuff what the others think.
So, once you've chosen a database platform, what do you do?
It is entirely possible to code direct to your platform's C (or other
language) interface. But it's probably better to grab something like
Serge's code (for your chosen database, to be sure) and use that - it
saves re-inventing the wheel, if nothing else.
However, and this is a big however, once you've done this you are
_tied_ to using a particular database unless you want to do a _lot_ of
refactoring. If you find that your chosen database doesn't scale
enough, or it's too damn big to distribute with your app, or you
suddenly find yourself needing something that your chosen platform
doesn't provide, or the licensing terms just plain bug you, changing
becomes a big problem.
How to resolve this? What we're looking for is something that
abstracts the user code from anything that is tied to a particular
database. Something that lets the developer take the database as a
'given'.
If we were coding a Perl application (and that's possible on OSX, even
doing GUI if you use CamelBones), we might consider using DBI/DBD,
which isolates the database behind a database independent layer. Of
course, Perl, despite kicking enormous amounts of ass, is not
necessarily the fastest of solutions. There are similar solutions for
Java, including Apple's own EOF (part of WebObjects). But we don't
like Java. Well, _I_ don't. I like Objective-C. However, for
Objective-C, there is no longer an Apple-supported database abstraction
layer. There used to be one, shipped with OSX, up until at least the
public beta days. It was called EOF (Enterprise Objects Framework) and
it rocked more than a very rocking thing. But no longer. Objective-C
EOF has been 'Steved', much like a whole load of other stuff that I
used to be able to use (and that is now cluttering up my attic), and
replaced by Java EOF. Which is OK if you like Java. But, as I said
previously, I don't. When I'm coding Cocoa stuff, I use Objective-C.
Now for the bit where _I_ am biased[1]
There is good news, however. There are people out there who have
written replacements for much of EOF (the GNUstep project have
EOControl and EOAccess, MulleKybernetik have EOInterface, and I've
hacked some nasty IB code together and a very rough model editor).
Patches and code available from the link in my .sig at the bottom of
this mail
Using EOF (especially now it's no longer supported by Apple and not
installed on OSX) adds more stuff to be checked / installed at
application delivery time, but it's worth it, believe me. You can go
from a simple flat file database to an big, enterprise level database
(and no, I'm not talking MySQL or even PostgreSQL here, more like
Oracle, Sybase or DB2) with no changes to your code. You can build
much of your application within IB without having to write any code.
Having said that, there is a relatively steep learning curve, and for a
simple application it's probably not worth the effort unless you
already know EOF. For that, I'd stick with something that can be
packaged in the app. But for anything that needs to scale, is likely
to grow, or is bigger than a simple AddressBook.app replacement, I'd
strongly recommend looking at EOF[2][3].
Oh, there are other possible solutions. STEnterprise springs to mind
as a (relatively) platform independent way to access databases, and
Stone have a persistence layer around somewhere (StoneFreeObjectStore,
IIRC) which could prolly be hacked to be useful. There's bound to be
other stuff out there, too.
Simon
[1] I am doing lots of work on getting GNUstep's gdl2 into a workable
state on OSX. Patches etc from the address below.
[2] And, while you're looking at it, bother Apple at
bugreporter.apple.com. Give them valid business reasons why you _need_
EOF, why it has to be Objective-C, how much money it's costing you to
not have it. Don't just scream bloody murder; be calm, objective, and,
above all, have figures.
[3] It should be noted that EOF is more than just a database layer.
But if you only need the non-database bits (i.e. the really nice
qualifier and control parts), check out bDistributed.com for
BDControl.framework and BDRuleEngine.framework which may assuage your
cravings. They certainly did mine.
- --
Objective-C Enterprise Objects resurrected on Mac OS X.
<
http://www.tufty.co.uk/Software/EOPage.html>
- --
PGP Key Id : 0x50D0698D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE/bH3eRKxFDFDQaY0RAgQfAKCXtM+RVuumG1x9Wcb+7ZU8TLYIqQCgguLi
kTvZ7Th4gxQJRcjvhBD1EPU=
=ZbSC
-----END PGP SIGNATURE-----
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.