MacResearch

I've been using Core Data for a lot of things lately. Not directly scientific applications, but often for tools I use to manage application repositories or in applications where I quickly want to create a tool that needs to manage information for a scientific project.

In many cases the schemas are pretty straightforward. I know there are other applications that have been developed that use Core Data extensively (I believe Papers does so, Alex (Mek) can probably comment on that).

I'm finding Core Data to be an excellent tool as it requires very little code to make useful tools for managing information. Which means less time working on the tools and more time focusing on actual work.

What type of applications did you have in mind?

Dave

Hi,

I am currently writing some calculation modules for computational chemistry. I was hesitating to use CoreData, but did not in the end, because I was not sure whether there would be an impact on performance.

The idea here would be to store molecular data, in particular coordinates, atom information and eventually some properties. A few of these structures (like the coordinates) would need to be accessed from the calculation module. The calculation module itself is written in C for performance issues. Could / should I still use CoreData for accessing the coordinate data?

Thanks for any hints.
Marc

NB: another - but in my case secondary issue - is of course portability. If the tool you write is generic, it would be nice if it could be ported to eg Linux without too much effort. If I'm not mistaken, CoreData would be a no go in this case, or are there replacement GNUStep classes in the making?

Yes and no. We all know 90% of time is often spent in 10% of code. You don't use Core Data for that performance critical 10%. On the other hand, there is a lot of code we write for setting up the problem and saving the results. That's where Core Data comes in. Regarding portability, a complete Core Data program will not be portable, however, that's not the point. What's important is that the Data Model Schema used in Core Data program be well designed by the experts in each scientific field. Remember the rule: Design to the Interface, not the implementation. If the scientific community could work together to design Data Model schemas with common (agreed upon) interfaces we could pool together and save ourselves a lot of work. Core Data is just one developer environment for designing and implement these Data Model Schemas. There are other environments for other platforms. The Data Model schema (and interface) will be "portable", and should be shared freely.

UML is another way to specify the Data Model. While the Core Data Model graphs look similar, they are not as detailed in describing the model. Ultimately, I think UML is probably needed to properly share the Data Model. On the other hand, I'm impressed with all the code that Core Data generates for free given only the Data Model graph. Are there any other developer environments like that?

Apple has created the Corerecipes example, but quite frankly it's too complex for a good beginners tutorial (it does show many aspects of creating an iTunes like app).

By now there quite a some examples that should give you a better beginner's overview, just have a go in google

The ones from CocoaDevCentral are great:
http://cocoadevcentral.com/articles/000085.php

Then there's the NSPersistentDocument core data tutorial.

And check the ADC movie by Jonathan 'Wolf' Rentzsch, it's really good.

Also make sure to have a look at Malcolm Crawford's bindings examples, because especially when combined with bindings CoreData rocks:

Hope that helps,
Alex

We're using CoreData heavily in the physiology lab in which I work. I've written a data acquisition program that writes data acquired from D/A converters, video, or digital sources to a CoreData database. We have a matching database query tool that allows us to query data from the entire lab's aggregated data, from CoreData files stored on a server. It's proven to be an immensely powerful tool for writing complex query and visuazliation tools quickly. With Leopard, we've noticed a significant performance boost too (it's nice to get these boosts for free when Apple updates CoreData). Furthermore, with the schema migration tools in Leopard, we're able to more freely change the database schema as needs change while maintaining backwards compatibility with old data (this was possible in Tiger, but a lot more work).

WRT to sharing data using CoreData, the sensitivity to the schema details and version would probably make native CoreData files a bit difficult to use across many applications or users. There are many domain-agnostic data formats such as HDF5/netCDF or even some XML schema that are pretty easy to map to entities in a CoreData schema. I would imagine that settling on one of these common data formats would be easier in the long run.

barrywark (or anyone else):
Would you mind providing some details on how you implemented your acquisition program with coredata? I work in a neurophysiology lab that collects similar data, and I am working on organizing a database for our data. It sounds like you have a similar solution already, so if you could fill me in on how you designed the app, I would appreciate it!

Also, has anyone else done anything like this, in coredata or in another database? I am also toying around with implementing our data storage in another database, such as mysql or postresql, or even sqlite. Does anyone have experience with a similar situation? In more detail, I record neurological data from human subjects in a series of sessions; so far I have about 25 GB of raw EEG data, not including notes, video, etc. It has gotten to the point where it is difficult to keep it all organized, and a database seems to make sense. Do people store the raw data in a database (eg, individual samples of EEG, which would easily be over 4 billion entries at this point), you just store a pointer to all of the files on disk, a la iTunes?

Thanks!

Hi!

I got interested in the parenthesis in barrywark's post and was just wondering if anyone could give me a pointer as to how one would tackle a schema migration in Tiger.

Regards,
Fredrik

Just getting started with Cocoa, but thinking about using CoreData from the start.

All of the examples I've seen so far have a single unified data model. How do you do more than one? For example, suppose we have a molecule database like some of those described above. Now, perhaps we want to create a program that does e.g. thermo calculations of some kind with those molecules; there is likely to be a data model for the thermo program that has other entities and relationships, but one of the kinds of entity will be a molecule, and we want to refer to those in the existing core data molecule "library"

How is that supposed to be done?

Clear enough to give me somewhere to look, thanks.

The one issue is that I think I'd prefer these models to live in different storage places. In other words, one of them is like a library of chemical species (for which I may indeed have a core data-based editor), but the other one might be e.g. a chemically reacting mixture, and I might store the identity of its species and perhaps compositions, T, P etc there. I want to be able to refer to the chemical species in the reaction model, but I don't want to persist to the same place.

Does that make sense?