Re: Core Data with ODBC databases?
Re: Core Data with ODBC databases?
- Subject: Re: Core Data with ODBC databases?
- From: Mikael Hakman <email@hidden>
- Date: Wed, 16 Oct 2013 17:55:14 +0200
Yes, it is an interesting topic, isn't it?
The problem of concurrency and locking is not unique for Core Data. These 2 issues affect every application that accesses a multiuser database, whether you use Core Data or ODBC or some native access methods. This is because you cannot hold locks or be in a transaction over an user interaction. If you do then it will lockout other users indefinitely (like when you go to lunch or home without closing your application). If you don't and you commit or release locks before an user interaction then the database may be changed by others in unpredictable ways while you are looking at the screen and thinking. There is no silver bullet for this problem. In my applications I use a button 'Reload Data' which reloads all application data. In Core Data I use NSManagedObject refreshObject:mergeChanges looping over all objects. I set 'mergeChanges' to yes so that user changes are preserved during refresh. Another useful button is a 'Commit Changes' button which commits everything to the database. This is about all you can do if your database is multi user/application, independently of which tool you use to build applications.
You are right, the intention with my Persistent Store for ODBC is an easy way to use bindings for getting data to/from the view and from/to database. The second reason, as you point out, is ability to use the XCModel to manage and create databases. These are not bad reasons at all, wouldn't you agree?
In mentioned above software there is also a layer that supports ODBC in an Objective-C manner without Core Data involved. It makes the programmer's work a little easier than using 'native' ODBC library calls.
Yes, I agree there are differences in SQL supported by various vendors. I try to stay within ODBC standard SQL.
OK, you can answer to me directly via email.
/Mikael
On Oct 16, 2013, at 3:14 PM, Andrew Satori <email@hidden> wrote:
> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden> wrote:
>>>>
>>>> Hello,
>>>>
>>>> How can I use Core Data with ODBC databases? Thanks.
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (email@hidden)
>>>>
>>>> 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:
>>>>
>>>> This email sent to email@hidden
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden