It seems that database programming on Apple platform isn’t a mainstream. So little information I could gather in this topic. I want to make a simple mac database app which connects to a remote Firebird sql server (or any database for that matter, I also use Oracle and DB2 as well). I don’t want to use Core Data or web service as I think it’s too much adding unnecessary complexities. The app won’t be deployed on the internet in any way, just for closed local company intranet. I want the old-school and classic way; setting up connection, send some sql queries, get back the result set, close connection.
You’re right; connectivity to real,standalone database systems in a Client/Server fashion is a tough subject on Cocoa, and probably not easily doable w/o working very low-level, directly with a database driver. That said, talking to database systems in a Client/Server fashion is also bad practice, so i;m not sure if that’s not maybe a blessing in disguise.
IMHO for most scenarios, you should the be looking at an embedded database (say SQLite, which has nice wrappers available) or a roper multi-tier approach (say using something like out Data Abstract library and technology). And end-use app that connects directly to a remote database is almost always a bad idea.
SQLite is not really considered as a true RDBMS. It’s just an embedded, single user, single threaded, mini database system. It’s far more incapable compare to Firebird, Postgre, let alone Oracle and DB2. It’s completely out of consideration for whom needed a true RDBMS.
And, client/server fashion may be old, but it’s not a bad practice. It can be as good, secure, easy, and productive as other mechanisms. Also, I think a good development tool should not restrict on how the developers choose the way they do something because it’s completely the developer decision. Instead, a good dev tool should provide as many as possible mechanisms, scenarios, and use cases. For a simple data entry or retrieval, in a controlled restricted environment, a multitier approach (Data Abstract or tiOPF like) is overkill. We don’t need a bazooka to kill a mosquito.
I do hope some day in the future, RemObject would provide a framework similar to Delphi’s dbExpress. A native multidatabase connection layer for direct communication to --at least popular-- RDBMSes. I personally need this for my clients. My apps used to be written in Delphi, but now they want those apps to be available for Mac as well.
And we don’t restrict anything here. You can use any db library thats out there. it just happens to be the case that there unrest many Client/Server DB libraries for Mac OS and iOS. That’s not a “restriction”, just the reality of the platform (and driven probably by what most people consider good/bad/common practices).
Yes, that’s what I meant by restriction. I don’t expect an advance framework like Data Abstract, I know it’s too much of a demand. But a simple Nougat abstraction for core database functions to any popular databases would be very helpful for someone like me who came from Delphi background.
Thats not something that should be developed (by oust or anyone) of Nougat — it should be developed for Cocoa in general, if there’s demand for it. It’s just not something we will do given (a) we don’t have infinite resources to implement everything that can be implemented and (b) its a rather niche need since (as i explained before) not many people sttill use the outdated Client/Server modulate access remote databases.
This is simply a false notion. Every other languages have the required wrapper to directly connect to --at least-- popular RDBMs. Because that’s how it actually works. Delphi has dbExpress, FreePascal has SQLdb, PHP has PDO, Java has JDBC, .Net has LINQ, etc. And since it’s available on many popular languages and used by many programmers, you can’t say it’s a niché or outdated. In fact, it’s quite common. Even if one want to access a database indirectly (through a remote tier or an object persistence layer) s/he still needs to have the direct connection part.
Except on Apple platforms and Oxygene. Apple can run away from it because almost all servers are not run on OSX, they’re either Windows or Linux servers. Oxygene can run away from it because it stays on top of a managed environment --.Net or Mono and Java-- which already covers such need. It’s maybe also RemObject has a product that encourage indirect database connection, Data Abstract. So, if one --me for example-- want to write an app that need to connect to a remote database, I have to write the remote service part either using other languages, or using Data Abstract.
You’re confusing languages and frameworks. This is not a language matter.
No, you have two words to many in that statement. It’s Cocoa that doesn’t have data access libraries. It’s not Oxygene’s task to provide em. Oxygene has nothing to do with this equation.
All of the platforms you list are used (either exclusively/primarily, or in Delphi’s case at least occasionally, to write server code. Of course you need touches a database directly on the server. How else would you write a middle tie server. Cocoa is never used as a server platform.
Direct Client/Server database access has no place in a client application written after 1999.
No. But a programming language is not just a language. It’s a tool that comes with its companions, the RTL, supporting libraries, first-party frameworks, etc. Especially nowadays when programming language becomes smarter and more complete. A modern programming language nowadays is a toolbox. Otherwise, it’s just nothing, and noone would be able to use it without writing lots of stuffs.
I disagree with this as well. I think Cocoa does provide data access library, the CoreData. What Cocoa doesn’t provide is the direct data access libraries. But it’s provided by the database engine vendors. All major database engines have their data access libraries available for OSX, ready to use. Now, I think its Oxygene task to bridge those 2 things: Cocoa’s CoreData and RDBMS’s data access library. Just like dbExpress in Delphi, or sqlDB in FreePascal, or Linq in C#, etc. Well, at least on OSX platform. I understand why we shouldn’t do direct database access from iOS.
I don’t know the situation in US or EU. But in most other countries, this technique is still widely used to this day. Especially in a controlled private intranet for a desktop app. It’s much easier, faster, and cheaper to do it this way than the more complicated multi-tier technique.
if you have such data access libraries, you can use them with oxygene. theres no bridging needed. Oxygen has full access to Cocoa frameworks and libraries.
You forgot one important adjective though: insecure.
In any case,we can argue all we want about whether multt-tier is needed or Client/Server is fine, and thats all fun and everything. But fat is that we’re not going to build a Client/Server database framework (for OS X or otherwise), ever. It’s not a technology we are interested in, and that’s the end of it, sorry.
I’ve pointed to reasons and alternatives. You don’t have to accept those reasons, but there’s little point in arguing about them further,
I cant seem to find any database vendors using it.
I’m doing something over the web but I think even it was in an intranet I would still create a webserver in .net and use http calls from the cocoa app.
Core Data is a local ORM. it’s not a library for accessing remote databases. IAUC, Bee wants to explicitly and directly connect to a RDBMS system like Microsoft SQL or InterBase, from their Mac or iOS client app.
