This is a tool for generating the same xcdatamodeld files that Xcode does when designing a datamodel for Core Data. It is written in pure ruby, but it will be of particular interest to RubyMotion developers. It offers the essential features that Xcode does, plus a text-based workflow and some niceties, like automatic inverse relationships.
ruby-xcdm is maintained by Infinite Red, a web and mobile development company based in Portland, OR and San Francisco, CA.
Add this line to your application's Gemfile:
gem 'ruby-xcdm'
And then execute:
$ bundle
Or install it yourself as:
$ gem install ruby-xcdm
- Make a directory called "schemas" inside your RubyMotion project
- Create one schema version per file within the directory
- To build the schema, run
rake schema:build
If you want to build the schema every time you run the simulator, add this to your Rakefile:
task :"build:simulator" => :"schema:build"
You can override the name of the datamodel file, if you need to, using a config variable:
app.xcdm.name = "custom"
- Make a directory to hold your schemas (a.k.a. data model in XCode parlance)
- Create one schema version per file within the directory
- Run the command to generate a datamodel:
xcdm MyApplicationName ./schema ./resources
Here's a sample schema file:
schema "001" do
entity "Article" do
string :body, optional: false
integer32 :length
boolean :published, default: false
datetime :publishedAt
string :title, optional: false
belongs_to :author
end
entity "Author" do
float :fee
string :name, optional: false
has_many :articles
end
end
All the built-in data types are supported:
- integer16
- integer32
- integer64
- decimal (See note below)
- double
- float
- string
- boolean
- datetime
- binary
- transformable
NSDecimal is not well-supported in RubyMotion as of this writing. They are converted to floats and lose precision. HipByte is aware of the issue and intends to fix it, but until they do, you will need to use something else for storing currency. For an example, see here.
Inverse relationships are generated automatically.
If the inverse relationship cannot be derived
from the association name, you can use the :inverse
option:
entity "Game" do
belongs_to :away_team, inverse: "Team.away_games"
belongs_to :home_team, inverse: "Team.home_games"
end
entity "Team" do
has_many :away_games, inverse: "Game.away_team"
has_many :home_games, inverse: "Game.home_team"
end
Many-to-many relationships are supported via the :plural_inverse
option:
entity "Person" do
has_many :threads, plural_inverse: true
end
entity "Thread" do
has_many :people, plural_inverse: true
end
In this mode, Core Data will automatically create a relation table behind the scenes. If you want more control, you can make the intermediate table yourself:
entity "Person" do
has_many :postings
end
entity "Thread" do
has_many :postings
end
entity "Posting" do
belongs_to :person
belongs_to :thread
datetime :joined_at
end
You can also have symmetric one-to-one relationships via has_one:
entity "Person" do
has_one :ego
end
entity "Ego" do
has_one :person
end
Deletion rules can be easily set on relationships and the default rule is "Nullify":
entity "Discussion" do
has_many :messages, deletionRule: "Cascade"
end
entity "Message" do
belongs_to :discusion
end
# Example:
# Discussion.first.messages.count => 10
# Messages.count => 10
# Discussion.first.destroy
# cdq.save
# Messages.count => 0
Core Data has no equivalent of :through
in ActiveRecord, so you'll
need to handle that relation yourself.
If you need to set some of the more esoteric options on properties or relationships, you can include the raw parameters from NSEntityDescription and NSAttributeDescription, like renamingIdentifier or defaultValueString.
Additionally, if you need to set some userInfo
properties, you can do so by
adding a user_info_entry
to an entity:
entity "Person" do
user_info_entry 'my_key', 'my_value'
end
To create new versions, simply copy the old version, increase the version string (the last one in sort order is always interpreted to be the current version) and make your changes. So long as they conform to the automatic versioning rules, everything should work seamlessly.
- Fork it
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Add some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create new Pull Request