I'd like to take this a step further. CoreData is a really nice tool, but CoreData really isn't the tool for using a multi-user RDMS since it skips over some of the frequently forgotten concepts like locking and data concurrency. Most of the time when people talk about CoreData and ODBC, they are really looking for one of two things, an easy way to use bindings for getting data to and from the view, or the ability to use the XCModel tools to manage and create databases.
In the first case, there are many solutions, none are right or wrong, but each may work well for your needs. Truthfully, the most simplistic is load the recordset into an NSMutableArray of NSMutableDictionary objects with custom code to generate the appropriate SQL for the save (update/insert/delete) process. The most complex is to custom code each table into a pair of NSArray/NSObject subclasses that handle all the nitty gritty details (and validations). This is a good bit of work, and I've done it a few times when I felt it was warranted. The middle ground is a mix of both, with a generic data object that manages the sql generation and fluff on the fly but let's you create inherited objects that appear to be those complex objects, and give you great control over validation at the field level. One of the big issues here, and I suspect why we have CoreData from Apple, instead of a modernized EnterpriseObjects is that ODBC is nice, but the various dialects and subtleties between RDMS platforms means that to be platform flexible, you have to allow your data layer ways to provide your own SQL language. It increases the complexity (and reduces performance) by a large margin, and ODBC itself is already a relatively slow layer. For what it is worth, I've been down all of these paths, (ODBCKit, PGSQLKit, etc). If you really want to talk in more detail about it, I would be happy too, but IMO, it needs to go off list, as we will quickly find ourselves outside the realm of Cocoa itself. In the case of the second, it would be possible to create a layer much like BaseTen was for PostgreSQL, but honestly, the XCmodeler lacks too many features to make this practical. Dru On Oct 16, 2013, at 6:58 AM, Mikael Hakman <mhak...@dkab.net> wrote: > I used the NSIncrementalStore to create an OdbcStore so that you can use Core > Data with ODBC databases. You find it on > https://github.com/mhakman/osx-cocoa-odbc. > > /Mikael > > On Oct 16, 2013, at 12:12 PM, Zac Bowling <zbowl...@gmail.com> wrote: > >> CoreData is not an ORM. It's a object database that happens to use SQLite. >> >> That said NSIncrementalStore could be used to store there but it would be >> massive amount of work. >> >> Sent from my iPhone >> >>> On Oct 13, 2013, at 2:52 PM, Leakim Namkah <leakim.nam...@gmail.com> wrote: >>> >>> Hello, >>> >>> How can I use Core Data with ODBC databases? Thanks. >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/zac%40zacbowling.com >>> >>> This email sent to z...@zacbowling.com > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
