The question pretty much says it all.
I'm new to Ruby and Rails and I'm trying to figure out active record. According to a few pieces that I've read, Rails will interrogate the database (in my case PostgreSQL 9.6) and pick up the columns from that. The way I read this, does that mean I can create the database in PostgreSQL, create ORM classes and define the relationships in the ORM classes?
My background is in databases and it's been a while since I've done any web development and prior to 1/8/2018 I had never even touched Ruby let alone Rails. So, the ultimate question is: Can I create the database in PostgreSQL without Rails migrations and then create the ORM classes with the relationships between the classes (tables) defined in them?
Yes, absolutely! You'd just need to connect to the existing db in config/database.yml and generate a schema file by running rake db:schema:dump. Remember to go by Rails naming conventions for ORM Classes (called Models in RoR). You can also explicitly set table names for every model by adding self.table_name = "posts" (see this answer)
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 am presently designing a database schema for use in a Rails 3.1 application.
At the moment, I am using MySQL Workbench to design the schema visually, and then manually translating this to Rails migrations & models.
Can anyone indicate if there are any solutions that will allow a schema to be designed visually and translated automatically (i.e. via script) to Rails?
Thanks!
First off, the "database-first" approach definitely isn't really the preferred way to work with Rails... but if you really want to...
If you generate the the tables from your schema you can configure the Rails app's config/database.yml file to connect to your database, then call rake db:schema:dump which generates the db/schema.rb file from the database. Then you can create a migration and copy the code from db/schema.rb into the change (or self.up) method.
Note that this does not automatically create model classes - you'll have to create these yourself, remembering to --skip migration in the rails generate model, and possibly needing to make liberal use of the set_table_name (to map the model class to the right table name), alias_attribute (to map model attributes to the right columns), and perhaps set_primary_key.
There were some more complete approaches to this sort of thing for older versions of Rails (Magic Model Generator and reverse_scaffold are two that I've found), but I don't know of any that have been upgraded to work with Rails 3.
SQL Editor is a Mac application that allows you to visually design a DB schema and then export it as something you can easily import as a schema in Rails.
You will still have to create the models yourself.
For rails existing applications or the new application, you can use this for db design
https://dbdiagram.io/
I use railshelper.com which helps me in a simplistic manner to generate quickly some common rails cli commands !
I think Mogwai ERD will help you out, there you can design your ERD and convert it in to a DB schema.
And I think there is no software for design Rails schema, it's just that you make your schema adhere to Rails conventions. But of course Rails can be configured to almost any schema.
Is it necessary to use db:migrate?
I have existing database, i want to write ROR classes for this and synchronize with DB.
How can I do this?
You do not. Your class name just has to match the table name. However, I would warn you that working with Active Record (the rails orm by default) against an existing db that doesn't have the ar conventions is going to be a huge pain. I would recommend checking out datamapper, and using rails 3 (since alternative orms in rails 3 is way easier)
I have a 'legacy' DB2 database that has many other applications and users. Trying to experiment with a rails app. Got everything working great with the ibm_db driver.
Problem is that I have some tables like schema1.products, schema1.sales and other tables like schema2.employees and schema2.payroll.
In the ibm_db adapter connection, I specify a schema, like schema1 or schema2, and I can work within that one schema, but I need to be able to easily (and transparently) reference both schemas basically interchangeably. I don't want to break the other apps, and the SQL I would normally write against DB2 doesn't have any of these restrictions (schemas can be mixed in SQL against DB2 without any trouble at all).
I would like to just specify table names as "schema1.products" for example and be done with it, but that doesn't seem to jive with the "rails way" of going about it.
Suggestions?
Schemas in DB2 are a very handy way to provide separate namespace to different applications. For example, you can separate all database objects for an application called "recruiting" from say application called "payroll". You can have objects (tables, views, procedures etc.) with the same name reside in multiple schemas and not colide with one another. Having your application set a schema is a handy way for it to say "hey, I am a payroll and I only want to work with my objects". So, what happens when you want to work with objects owned by another application? Well, in traditional procedural programming languages your application code would explicitly specify the schema when referencing an object in another schema or you would just do a SET CURRENT SCHEMA to switch to another schema. The problem with ORMs like ActiveRecord in Ruby on Rails is that you are not supposed to use SQL i.e. you don't have a good "Rails way" to specify schema when referencing an object. You can use find_by_sql and qualify your objects in the SQL statement but this is not what RoR people will consider to be good Rails.
You can fix things on the DB2 side. You can define a view per table in the "foreign" schema but you will have to take care to name the view so that it does not colide with what you already have in your primary schema. And, when you do that, you will undoubtedly create names that are not true Rails names.
Rails people are very proud of the "Rails way". It makes it very easy to create new applications. Rails is really awesome in this space. However, when it comes to integration with what is already out there Rails ... how do we say it ... sucks. I suggest you will have to accept to do things that are not the best examples of the Rails Way if you want to work with existing database structures.
How do i work with two different databases in rails with active records?
So what's the best way to create new tables in a Sqlite database in Rails 2. I have created the database using rake db:migrate command. So should I write individual sql scripts to create a database or use rake somehow. I don't need scaffolding.
Basically use migrations.
Some useful help on how to use migrations is available at http://wiki.rubyonrails.org/rails/pages/understandingmigrations and http://wiki.rubyonrails.org/rails/pages/UsingMigrations. A good cheatsheet that I use is also available at http://dizzy.co.uk/ruby_on_rails/cheatsheets/rails-migrations.
Basically migrations use ruby code to create your database tables for you. It is far easier (in my opinion at least) to use nice ruby code to do this rather than SQL DDL - it also does various things automatically for you (like adding id fields to all your tables as rails requires). You can then use rake tasks to actually apply the migrations to your database. The other major advantage that migrations give you is that they are reverseable - so your database is versioned and you can easily jump from one version to another.
Try to avoid writing CREATE/ALTER table scripts and use ActiveRecord migrations instead. A few reasons spring to mind:
Portability: it's much easier to let
AR deal with cross-platform flavour
differences
Change control: your
migrations can manage changes in
both directions with the VERSION=
option, something that's not easy to
do with SQL
It's the Rails way:
follow the Rails conventions unless
you have a compelling reason not to
do so
Simplicity: you don't have to worry about id and timestamp columns when you use migrations, which saves you having to remember them if you work in SQL
If you are not using scaffolding then you should use script/generate migration to create a migration file for each table. There is no need to use sql scripts. After creating some migrations you can apply them to your database using rake db:migrate.