So I'm new to Core Data, everything I read says to use it - if you use SQLite you're an evil bad person. But I'm lost on some simple things. I have a bunch of data that will be used to setup a NSCollectionView, this would be relatively simple in SQLite, but I don't want to be an evil bad person. Is there a simple tutorial someplace that I'm missing? I would love to see a example SQL database based app and the same thing with core data.
Something like here is a table structure in SQL, here is the equivalent in core data...
Here is a INSERT script in SQL, here is the equivalent in core data...
Here is a SELECT with a JOIN and a few WHERE statements, here is the equivalent in core data...
Its even the little things that I don't understand.
How do I provide a pre-populated core data system
Where do the core data files live? in the bundle like my SQLite database would?
With an update to the app what do I have to do to update the core data files if they live outside my bundle?
Justin808,
No one is an "evil bad person" for not using CD. If you prefer to use SQLite, go for it. It is used by many applications. It is a framework. If SQLite is a technology you are used to, then use SQLite. That said, CD is the Apple encouraged path for building rich, persistent model apps on their platforms. They don't provide many tools for the pure SQL community but provide a very rich set of tools for CD apps. I've attempted to answer the technology question here: Core Data VS Sqlite or FMDB…?
About your request for a line by line comparison between the same app implemented both ways, this sounds like an excellent learning opportunity for you to write one. (I teach beginning iOS programming. The app you're asking for can be quite simple. You can probably write both versions in one weekend. I would be happy to review your work and critique your blog post describing the differences. You could make an excellent contribution to other folks in your situation trying to choose between these two technologies.)
Your questions:
Something like here is a table structure in SQL, here is the
equivalent in core data...
Schemas are described differently but are substantially similar. That said, an SQL schema may not be tuned for use by CD and/or UI application or vice versa.
Here is a INSERT script in SQL, here is the equivalent in core data...
There are plenty of examples by Apple and others that tell you how to insert new entities. What is it you don't understand?
Here is a SELECT with a JOIN and a few WHERE statements, here is the
equivalent in core data...
The predicate language in CD is different than SQL. As such, you will query things differently. In particular, CD is an almost "pure" set theoretic approach to organizing data. You use fetches to seed your "query" and set operation to refine it. Beyond that, I need to direct you to one of the many books about CD and its predicate language.
How do I provide a pre-populated core data system
CD depends upon a file like every other DB system. You provide it in your bundle and copy it into your documents directory (on iOS) when you need to mutate it.
Where do the core data files live? in the bundle like my SQLite
database would?
Yes, they do. If you are using CD with a SQLite backing store, then it is just a SQLite DB file. (There is a special issue if you allow CD to store large BLOBs in the file system.)
With an update to the app what do I have to do to update the core data
files if they live outside my bundle?
I'm not sure what you are asking here? If you update your schema between versions, just as with SQLite, you will need to migrate your database to the new schema. CD provides some tools that work very well for additive migrations.
Good luck with your choice.
Andrew
Related
Nowadays SAP recommends to "keep the core clean" in order to be able to move to the cloud and always be able to update to the latest version without having to worry or retest, also valid for on-premise.
I got the requirement to add a Z field to the QMEL table to link its notifications to SAP PS projects (PROJ table). The QMEL table already has a structure -CI_QMEL- ready to be extended and the related BAPIs support this extension.
But in order to keep the core clean, I'm considering to challenge the functional requirement and suggest to create a ZNOTIF_PROJ table with the same key than QMEL (Notification ID). This would then become totally separated from the standard but at the same time the official BAPI wouldn't be able to support it, so a wrapper on top would be needed to update the standard and the custom and everything would become more complex.
Should I stick to the old extension style or go for a new table?
Personally I prefer extending standard tables. Having BAPIs, standard transactions, etc, work as expected is worth far more than a nebulous idea like a "clean core."
As long as you're not modding core code or extending tables in an incorrect manner, customizing the system in ways supported by SAP is not a bad thing. You should consider your future upgrade plans (S/4 on-prem vs cloud, for example) when deciding the right answer, but don't make things too hard on yourself.
S/4 on-prem or cloud already has adding new fields and tables functionality. We can do this in web UI look like SAP CRM. So there is no problem for extending existing structure. Help page about this functionality here.
I have legacy code that has DB connected.I'm trying to add new features for this app with Symfony2. I used Theodo Evolution Bundle to access the legacy session.
First thing that I want to do now, is to build an API that will use data from existing database. This database has tables that are not converted to entities. My question is which is best approach in this case. To use native queries from existing tables in database to build API or to convert tables into entities I used documentation for this part but I'm not sure will import all relations and everything) and then to build API. Can you please suggest me which is best approach in this case. Thank you.
The best approach in my opinion is to work with doctrine entities within the framework and to avoid direct SQL if possible. That is the basic philosophy behind frameworks such as Symfony: the database layer should be abstracted.
The entity-database mapping might be quite more of a hassle at first, because you can't rely on automatic tools to set it up, but once it's done it will be much easier to work out the rest of the application.
When I started to code my sinatra application I never used it before. Note that I had and still have no experience with RoR. I had one .rb file and one .haml and was happy. Now I had to split .rb file into about 10 'library' files as the whole application gets more and more complex.
I store some application logs/info in csv files and now I am getting conflicts when accessing the csv file. So I think that I need to introduce "proper" database solution. I want it to be part of my ruby (sinatra) application.
How can I introduce 'light' sql database into my sintra application?
I am on ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-mingw32] soon upgrading to 1.9 (hopefully)
I'd recommend looking at Sequel. It's very flexible and powerful, and works well with SQLite, MySQL, Postgres, Oracle and other DBMs. It's not opinionated about how you talk to the database; You can use it as an ORM or with simple datasets, and allows embedded SQL or more programmatic approaches.
For ORM, both ActiveRecord and Sequel are recommended. About database, I guess sqlite3 will be good enough for your need. Also you can choose mysql or pg.
If you want to use active_record, you'll find this article very useful.
And if Sequel is the choice, just read Sequel documents here.
After the gems installed. You can start writing some code to connect the db. Then maybe some migration task to build database tables (and don't forget build some corresponding models). Both gem have similar syntax for migrations. After that, import your csv data and well done.
I have had no trouble using either Active Record or DataMapper to add object persistence to my Sinatra apps. People also tell me Sequel is very good but philosophically it is not not worlds apart from Active Record imho.
Active Record and Sequel favour a more database-centric approach, whereby you spell out your tables as a set of database and table definitions in a collection of migration files and merge them into a schema which is then used to build or update your database tables. If you really care about the underlying SQL database then one of these is for you. I find them to be six of one, a half-dozen the other.
DataMapper is more object-centric and lets you define the properties and object relationships you need in your object's own class definition; and then when your app launches you make sure you call DataMapper.auto_upgrade! and it upgrades the database to suit your object graph. The upside is that you only have one place to look to find what properties your object might have. The downside is you have less control over the specifics of the underlying databases, though it's not impossible to tightly define the mappings, DataMapper works well when you care about object graphs over database tables.
The good news is they pretty much all work in the same way once you have your mappings from object graph to SQL database tables defined. All support lazy or pre-emptive loading of related collections of objects, many_to_many relationships, polymorphism, etc, and tend to vary only in configuration and seeding details.
I often start projects using DataMapper just for its speed of throwing up and tearing down database schemas, as the app's object graph is still in flux; I refactor quickly to use Active Record when the schema has settled down. Next project I think I'll give Sequel a go though, as people do seem to rave about it.
I have had success using datamapper with Sinatra, put like the other post you can also use Sequel and Active Record. One advantage to maybe using Active Record though is if you do ever want to use/learn ROR, Active Record is the default ORM so that might be something that you want to consider.
If you don't want to go the ORM route you can always use the SQL-Ruby gem which will allow you to create and run sql queries. Here is some example code from the website http://sqlite-ruby.rubyforge.org/
require 'sqlite'
db = SQLite::Database.new( "data.db" )
db.execute( "select * from table" ) do |row|
p row
end
db.close
I would like to know what I have to think about in order to download an SQL DB into core data? I am not sure what frameworks I would have to use or if there are any particular requirements when formatting the SQL DB.
Any help, suggestions, links to tutorials would be hugely appreciated.. I have done some searching around and its just hard to make sense of things because I am not sure if what I am looking for is even correct.
Im not sure if I understand what you are after, but maybe 2 links would be helpful:
an application that lets you load you data to a Sqlite DB from a lots of formats (Excel, xml, ...) is Navicat. It's an easy way of getting data to the DB. As David H mentioned, you could then work with the data without using Core Data via an Sqlite wrapper like FMDB. Then you can access the data with SQL commands.
A totally different tutorial is offered by nsscreencst.com: Importing into Core Data is a tutorial that shows how you can import JSON data to Core Data from a web API. This might be related to your use case. Unfortunately the videos there cost $9/month, but IMHO they are doing a terrific job.
(I'm not affiliated with either of the above companies)
This is just not possible - even though Core Data can use SQLite for storage there is no import/export. You really have two options:
1) If you have one database you want to use Core Data with within an iOS app, then you can write a really simple Mac App that interacts with your SQL store, and essentially replicates it in Core Data using a Core Data Schema you create based on your SQL database. The advantage of this is that is simpler to test and develop using a mac app. The final Core Data repository can then be used by your iOS app (by including the Core Data Schema with it).
2) Do all the import in your iOS app. This may take longer to develop but you can then dynamically download the SQL database into the phone and use SQLite to read it.
To import your data you have to create NSManagedObjects objects from every single record in your SQLite database. Depending on the complexity of your database model this can be very tricky.
There is a good introduction by Marcus Zarra on how to create NSManagedObjects from JSON: https://stackoverflow.com/a/2363996/480069. This should give you an idea on how to start. As Marcus said be aware of the relationships in your object graph so you don't end up in a loop when having complex relationships.
There are also a lot of good tutorials out there how to serialize NSManagedObjects, so just give Google a try: NSManagedObject serialize.
This is a problem that I come to on occasion and have yet to work out an answer that I'm happy with. I'm looking for a build system that works well for building a database - that is running all of the SQL files in the correct database instance as the correct user and in the correct order, and handling dependencies and the like properly.
I have a system that I hacked together using Gnu Make and it works, but it's not especially flexable and frankly can be a bit of a pain to work with in some situations. I've considered looking at things like SCons and CMake too, but I don't know how much better they are likely to be, or if there's a better system out there that already exists...
Just a shell script that runs all the create statements and imports in the proper order. You may also find migrations (comes with rails) interesting. It provides a make like infrastructure that let's you maintain a database the structure of which evolves over time.
Say you add a new column to some table. In migrations you'd write a snippet of code which describes the requirements for adding the column and also to rollback the change so you can switch to different versions of your schema automatically.
I'm not a big fan of the tight integration with rails, though, but the principles behind it are very interesting.
For SQL Server, I just use a batch file with SQLCMD.EXE and a bunch of .SQL files. It's not perfect, but it seems to work.
For my database, I use Migrator.NET
This is a .NET framework which allows you to create classes in where you define your DDL statements.
The framework comes with a command-line tool with which you can execute your 'migrations' in the correct order.
It also has a msbuild - task, so you can integrate it in a continuous integration build as well.
First export full DDL files describing all tables, views, source code
(procedures, functions, packages), sequences, and grants of a DB schema
See
Is there a tool to generate a full database DDL for SQL Server? What about Postgres and MySQL?
I created a database build system (part SQL-parser, part make file) to put these files together in a DB creation script using python.