Should I create AR migrations as I'm changing my models? I am using Mongoid and MongoDB so I do not see any benefits. The only benefit that I can think of is renaming a field - but that I can also do with small script. Would that even work? My gut is telling me that I do not need migrations, but I'd like to hear from someone with more experience.
What is the best practice? Should I use migrations with MongoDB?
Since MongoDB does not (as at 2.6) provide any server-side schema enforcement, data migration scripts are not strictly required. This can be particularly helpful for speed of development.
However, it may still make sense for you to create migrations for your production data if you want to practice good "data hygiene" and ensure consistency across different deployments.
For example:
removing unused fields
adding new required fields
setting default values
renaming fields
loading required data/fixtures
ensuring required indexes
You certainly have the choice of doing any of the above as one-off scripts or handling exception cases in your application code. For example, you can lazily add missing fields or defaults as documents are loaded from the database for editing.
For Mongoid in particular you may want to try the mongoid_rails_migrations gem.
Mongo DB documents are schema-less therefore migrations are not needed. You can just define fields in your mongoid models like:
field :name, type: String
Check the mongoid documentation for supported fields.
Related
I'm a newbie in rails and its a great platform.
I created an application but removed all the migration scripts.
I want to create the database with the tables from my existed models.
I can't find it on the net and I'm sure that might be an option to do that like any other platform (java hibernate, etc)
the command rails generate... only create the table without columns but I have columns in the existed models. so how can I do that?
Thanks!
If you've accidentally scrubbed your models and don't have any migrations, you can still generate a db/schema.rb file by running rake db:migrate and using that instead. It should reflect the current state of your database no matter what you've done to it.
If you create a migration with the important parts of this in it, as you'll notice the format is very similar, you will be able to replicate that configuration on other systems.
This is a bit of a heavy-handed way to do it, though. Each model should have its associated migration. Generally these are never deleted and only modified if strictly necessary, preserving a history of how the schema evolved into its final state.
If I understand your question correctly, there really isn't a way to construct your database tables from your ActiveRecord model classes - it's best to think of ActiveRecord models as more of a mapping between different flavors of relational databases and Ruby objects. In other words, ActiveRecord models abstract away the details of a database in order to become database-independent. They make your database data more easily accessible in Ruby. In doing so, they don't have the power to construct your tables. Think of them as very pretty getters and setters rather than a binding to a database.
This is exactly why migrations exist - they contain the database-specific stuff. They essentially contain the "other half" of your model definition - most of the application level stuff (like relations, which don't exist in, say, MySQL, right? They are an ActiveRecord convention) is defined on your model, but, for example, if you want to have a string on your Foo model, you define that in your migration, and the appropriate getters and setters will be available on your model for you to play with this string.
tl;dr: you need your migrations. The fact that they exist in Rails is an intentional design decision to separate the Ruby half of the models from the database half.
I'm a PHP programmer for over a decade and making the move to RoR. Here is what I'm used to from the PHP world:
Create DB schema in a tool like MySQL WorkBench -- and make fields precisely the size I want without wasting space (e.g. varchar(15) if it's ip_address).
Write models using Datamapper and place those exact field lengths and specifications in there so my app doesn't try to put in any larger values.
In the RoR world from what I've seen over the past two days, this seems to be the flow suggested:
Add fields / schema using the command line which creates a migration script and apparently created large ass fields (e.g. "ip_address string" is probably making the field varchar(255) in the db when I run the migration).
Put in validations during model creation.
Am I missing something here? What's the process in the RoR world for enterprise level applications where you actually want to create a highly customized schema? Do I manually write out migration scripts?
The scaffolding is what you use to get started quickly. But before running the migration, you can edit it and add constraints and specific column lengths.
Validations specified in the model (in the ruby code) does not carry the same level of security as validations /constraints specified on the database. So you still need to define those on the database.
While it is possible to work with Rails without migrations, I would strongly advice against it. In some cases it cannot be avoided (when working with legacy databases for instance).
The biggest advantage of using the migrations is that your database schema, accross different platforms, can be held in sync through different stages. E.g. your development and your production database. When deploying your code, the migrations will take care that the database is migrated correctly.
You can edit the migration scripts before you run the migration in order to customize the fields.
Yes, if you need to tweak the defaults, you edit the migration scripts.
Also note that you don't need to use migrations, they're a "convenience" while iterating through DB development. There's nothing that says you must use them. The active record pattern doesn't rely on how the DB tables/fields/etc. are created or defined.
For example, migrations are useless when dealing with legacy DBs, but you can still write a Rails app around them.
I'm wondering if working with rails (3) is a good idea when a huge/ugly legacy database is already there (Oracle, SQLServer).
I only have experience with ActiveRecord, is there another ORM more suitable for that kind of job?
Cheers
ActiveRecord can still do the job - for example there are directives that can be applied within your model that make non-conventional table names, primary key names (multi-column PKs, if you have them, used to require some additional work, not sure how true that is in AR3).
For both Oracle and SQL Server you're going to need to get the relevant DB adapters; I don't think either is bundled with AR.
A lot of legacy DB Rails work only needs read-only access - if that's the case - and you can get access to do so - then you may find that defining views that are more "AR-friendly" and referencing those through your models may make life easier. If update is going to be necessary then either a useable primary key will be needed or you'll have to consider dropping down to building and executing custom SQL, something that's fully supported in AR for occasions when the abstractions can't cope.
I'm learning Rails, and the target of my experiments is to realize something similar to Zoho Creator, Flexlist or Mytaskhelper, i.e. an app where the user can create his own database schema and views. What's the best strategy to pursue this?
I saw something about the Entity-Attribute-Value (EAV) but I'm not sure whether it's the best strategy or if there is some support in Rails for it.
If there was any tutorial in Rails about a similar project it would be great.
Probably it's not the easiest star for learning a new language and framework, but it would be something I really plan to do since a long time.
Your best bet will be MongoDB. It is easy to learn (because the query language is JavaScript) and it provides a schema-less data store. I would create a document for each form that defines the structure of the form. Then, whenever a user submits the data, you can put the data into a generic structure and store it in a collection based on the name of the form. In MongoDB collections are like tables, but you can create them on the fly. You can also create indexes on the fly to speed searches.
The problem you are trying to solve is one of the primary use cases for document oriented databases which MongoDB is. There are several other document oriented databases out there, but in my opinion MongoDB has the best API at the moment.
Give the MongoDB Ruby tutorial a read and I am sure you will want to give it a try.
Do NOT use a relational database to do this. Creating tables on the fly will be miserable and is a security hazard, not just for your system, but for the data of your users as well. You can avoid creating tables on the fly by creating a complex schema that tracks the form structures and each field type would require its own table. Rails makes this less painful with polymorphic associations, but it definitely is not pretty.
I think it's not exactly what you want, but this http://github.com/LeonB/has_magic_columns_fork but apparently this does something similar and you may get some idea to get started.
Using a document store like mongodb or couchdb would be the best way forward, as they are schema-less.
It should be possible to generate database tables by sending DDL-statements directly to the server or by dynamical generating a migration. Then you can generate the corresponding ActiveRecord models using Class.new(ActiveRecord::Base) do ... end. In principle this should work, but it has to be done with some care. But this definitely no job for a beginner.
A second solution could be to use MongoMapper and MongoDB. My idea is to use a collection to store the rows of your table and since MongoDB is schema less you can simply add attributes.
Using EntryAttributeValue allows you to store any schema data in a set amount of tables, however the performance implications and maintenance issues this creates may very well not be worth it.
Alternately you could store your data in XML and generate an XML schema to validate against.
All "generic" solutions will have issues with foreign keys or other constraints, uless you do all of that validation in memory before storage.
I'm developing some things in Ruby on Rails, and I've currently got several models with relationships between them. Now, the models specify the relations, so I know that RoR will enforce integrity, but what about at the DB level ?
Do other people set up foreign key relationships in DB tables ? and if so, how ?, there doesn't seem to be any way to setup/destroy a db relationship in a migration (maybe using raw SQL)
Thanks
Paul.
Here's a guide on how to do it:
http://seb.box.re/2006/7/29/foreign-key-and-rails-migration
There is also a plugin for this here:
http://github.com/harukizaemon/foreign_key_migrations/tree/master
However, Rails does not easily support foreign keys in migrations for a reason. Basically they're not really necessary when using ActiveRecord.
Here's a good explanation of why they are not necessary and their usage is discouraged in rails: http://www.motionstandingstill.com/i-dont-use-foreign-key-constraints-with-rails/2008-10-17/
Opinions differ on this subject. There's a good discussion here: http://forum.softiesonrails.com/forums/3/topics/138
There isn't a way to do it from the migration short of using SQL, which means that:
It's DB-specific
You have to use SQL
The first isn't really that big a deal (how often do you switch databases on a project anyway?), and the second is simply a fact of life. So, use them if you want.
Incidentally these things should always be set up at the database level. There are other ways to access and change data in the database besides the application. You should never set these types of rules in the application unless you want useless data. All things that touch on data integrity must be at the database level even if you have to (GASP) use SQL.