RE: Connecting to postgres using Cocoa Obj-C

FROM : Prekezes Ioannis
DATE : Fri Dec 24 09:50:38 2004

Andy thanks for the reply and  also thanks to Markus for his previous one .


At first I have to say that your comment for JDBC  was quite  alarming , so
maybe I have to reconsider the whole matter of Obj-C/JDBC.

What I am trying to accomplish at the present, is a working framework for
working with the 2 tier Client Server model, (no application servers or
other middleware) with as much as possible DB vendor independence.

I have also considered ODBC but my conclusion from my  little research so
far, is that you cannot  find ODBC drivers for all platforms or they come
from a third party with additional cost.

Can you tell me more about this C++ ODBC consumer,  Are you talking about
libodbc++?

Best regards
I. Prekezes


-----Original Message-----
From: Andy Satori [mailto:<email_removed>]
Sent: Thursday, December 23, 2004 5:36 PM
To: Prekezes Ioannis
Cc: MacOSX-Dev
Subject: Re: Connecting to postgres using Cocoa Obj-C


Don't forget that every copy of OS X since 10.2 has shipped with ODBC
support as well.

The drivers aren't as pervasive as they are on Windows, but the
infrastructure is there.  The weakness is that there is not (today) a
good Objective C method for consuming ODBC.  The reason I quit working
actively on my native PostgreSQL classes for Objective C / Cocoa was
because I switched the entire thing to ODBC about 2 months ago.  The
reason is that I now needed to be able to switch between PostgreSQL &
MSSQL (and Oracle to a lesser degree) and had a need to build C++ and C
based libraries that could be portable across platforms (Windows,
Linux, OSX) at the code level and Java really wasn't an option for the
project.

What I discovered was that due to some difficult to work around #DEFINE
problems in the ODBC headers, it's difficult to directly consume the
ODBC 'C' libs from Objective C.  Fortunately for me, I already had some
basic ODBC consumers in C++ and by reusing those, from Objective C++
(.mm is a magical and wonderful thing), I ended up with a usable
foundation fairly quickly.

Again, the downside is that it requires some odd basics.  I've been
toying with the idea of an OSS (MIT/X11 license) project to build a
'Cocoa' Objective C ODBC database library modeled on ADODB to make it
easier for those Windows developers that are coming over from the dark
side :-).

EOF, ARJ and the others really are cool technologies, but they
introduce another learning curve, and in my experience with them, they
are excellent for rapid development from the ground up, but have
serious weaknesses when building applications against existing
databases that don't use serial primary keys.

I also looked at the JDBC avenue, and ultimately after testing
concluded that performance of that approach was not really robust
enough to serve my needs.  The performance of JDBC in a Java
environment is outstanding, but the introduction of the Java Bridge
created a bottleneck, and the memory demands of my project skyrocketed
to the point where a G3 iBook with 512mb was being crushed by the
client process.

Ultimately, I ended up with two seperate designs that I'm using for
different projects.  One is a traditional Client/Server model that uses
native platform UI toolkits and shares a common C++ library that
implements the business layer and db CRUD objects via ODBC.  The second
is a more n-Tier design that utilizes Java Web Services, EJB and a JNDI
datasource using JDBC to get to the database, with native platform UI's
that do nothing more than consume the web services.

The client/server approach is more work to deploy and manage from a
networking point of view, but it performs significantly better.  The
weakness is that it is ill suited to high latency / low bandwidth
environments and needs direct IP connectivity to be used since you
don't as a rule want your database layer exposed to the internet at
large.

The Java Web Services (SOAP) approach is slow.  Partially because the
bloat of the data on the line for a SOAP transaction, partially because
of the intrinsic design compromise of a stateless Web based
transaction, but it offers a freedom of location and bandwidth demands.

In both cases, I'm wedded to platform native UI's, and I'm in an
environment where I cannot commit to a 100% Mac restricted solution, so
much as I love the Objective C language, I can't really use it for
everything.

Ultimately though, your needs should dictate the toolset.  If you can
use it, EOF (WebObjects) is a worthy purchase and toolkit for the Mac. 
  The n-Tier design is better suited to the enterprise world where
having central servers and widely distributed clients is a more
attractive design style.  There is, however, a lot to be said for the
ability of an application designed in the Client/Server model to scale
down to a single user, and up to several hundred without any real
difference in architecture or implementation, and while WebObjects /
EOF are capable of this too, it's not really the focus in my mind.

WO(EOF) and ARJ and GDL are all options, but for me, they simply don't
meet the demands of the projects that I'm working on.

Andy


-----------------------------------------------------
<email_removed> - druware software designs
http://www.druware.com

"Life should NOT be a journey to the  grave with the intention of
arriving safely in an attractive and well-preserved body, but rather to
skid in
sideways, chocolate in one  hand, martini in the other, body thoroughly
used up, totally worn out and screaming "WOO HOO what a ride!"

On Dec 23, 2004, at 7:19 AM, Prekezes Ioannis wrote:

> I am observing with a lot interest this conversation concerning
> connectivity
> to postgress, since I am doing, at this time as newbie to OSX/Cocoa
> development, my own home research for Cocoa/DB connectivity.
>
> I downloaded also the AJR sources and what I can say is that there is
> a lot
> of work done there. However there are no Oracle or MySql or DB2 or ..
> adapters included, so AJR is no usefull for me as it is, and the same
> reason
> I dont think that can be used as general DB connectivity framework.
>
> I have worked for years with VB/ADO, Java/JDBC Oracle/OCI ESQL etc and
> my
> conclusion at this time (maybe I am wrong) is to go with JDBC using the
> cocoa/java bridge since there are JDBC drivers for most of the
> databases out
> there.
>
> I dont know I anyone has created JDBC wrapper classes for Objective-C
> and if
> someone knows something about it pls let me know.
>
> All the best
> I.Prekezes
>
> -----Original Message-----
> From: Helge Hess [mailto:helge.<email_removed>]
> Sent: Wednesday, December 22, 2004 10:50 PM
> To: Markus Hitter
> Cc: MacOSX-Dev
> Subject: Re: Connecting to postgres using Cocoa Obj-C
>
>
> On 21. Dez 2004, at 14:42 Uhr, Markus Hitter wrote:

>> There is actually a third, not very complete clone somewhere in the
>> depths of OGo <http://www.opengroupware.org/>.

>
> Actually its pretty much complete, but its a clone of EOF 1.1, not EOF
> 2.x or up (therefore not very interesting for WO 4.x porters or in
> general).
> More exactly its a maintained variant of GDL 1 with some stuff added
> and some stuff removed (forked several years ago).
>
> In addition SOPE has some pretty good (EOF 2.x like) EOControl class
> implementations which the IMAP4, LDAP and some other stuff is based
> upon. But it isn't complete for DB apps (nor used in sope-gdl1).
>
> http://sope.opengroupware.org/
> http://svn.opengroupware.org/SOPE/trunk/sope-gdl1/
> http://svn.opengroupware.org/SOPE/trunk/sope-core/EOControl/
>

>>  They move to GDL2 in the long term, IIRC.

>
> Very unlikely.
>
> Maybe SOPE will add GDL2 to complete the WebObjects implementation once
> GDL2 is considered sufficiently complete and stable for porting WO
> apps, but OGo itself will stick to GDLAccess for the foreseeable
> future.
>
> I would also be _very_ interested in comments on the completeness of
> the AJR implementation and would appreciate any feedback (especially
> porting experiences) on that.
>
> best regards,
>    Helge
> --
> http://docs.opengroupware.org/Members/helge/
> OpenGroupware.org
>
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>