Added support pg from box and update installation doc
Created by: zzet
Added support postresql database from box installation without error and updated installation doc
Merge request reports
Activity
Created by: zzet
Looks like a hack.
thx
What about schema.rb?
added. What about autoupdate db/schema with run rake db:migrate?
Do tests pass?
yes. With fix models. Code attached.
p.s. updated to upstream. p.p.s. Do you really support sqllite? Look at the test...
By Administrator on 2012-10-08T17:41:02 (imported from GitLab project)
By Administrator on 2012-10-08T17:41:02 (imported from GitLab)
Created by: zzet
Ok. Code updated.
But after run rake task this hack will be overwritten…
May be not use rake db:setup?
rake db:setup # Create the database, load the schema, and initialize with the seed data (use db:reset to also drop the db first)
We can create db, run migration and load seed data… This would be equivalent, but it will not be necessary to remember about the hack ...
С наилучшими пожеланиями, Андрей Куманяев. -=-=-=- тел. : +7 (8422) 43-01-51 (c 20:00 до 24:00 + автоответчик) тел. : +7 (8422) 27-09-83 (c 20:00 до 24:00) моб. : +7 (9510) 99-93-93 (с 09:00 до 21:00 пн-пт) web : http://zzet.org icq : 635529 email : me@zzet.org skype : zzetik -=-=-=-
On Tuesday, 9 October 2012 г. at 0:47, Valeriy Sizov wrote:
What about autoupdate db/schema with run rake db:migrate? when you run db:setup then schema.rb will be used.
— Reply to this email directly or view it on GitHub (https://github.com/gitlabhq/gitlabhq/pull/1623#issuecomment-9239673).
By Administrator on 2012-10-08T21:05:41 (imported from GitLab project)
By Administrator on 2012-10-08T21:05:41 (imported from GitLab)
Created by: zzet
migrations is not an options. DB should be build from schema for new instances.
It is quite possible, especially if used in the migration models that have been removed or rewritten so much that the fall migration to fail. But you do not have the practice of zero migration? not always possible to use the scheme because schema.rb not affect things that are not described in the DSL. such as triggers. this way means that it is often necessary to move away from the side rb to sql schema (migration). it is changing the config.
You'll want to use rake db:migrate any time you have generated a new rails migration and want to have those changes applied. So, any time you modify your database, you'll run rake db:migrate.
Rake db:setup is used only when you are setting up a new db on your app. Rake db:setup is actually a shortcut for running rake db:create; rake db:schema:load, and rake db:seed.
If we have to work correctly migration or zero migration - the launch rake db:create && rake db:migrate && rake db:seed will not only bring the same result, but it could be better.
By Administrator on 2012-10-09T13:13:48 (imported from GitLab project)
By Administrator on 2012-10-09T13:13:48 (imported from GitLab)
Created by: dzaporozhets
- No real reason to use database triggers in GitLab
- schema.rb is more readable than sql
- building db from migrations slower than from schema.rb
By Administrator on 2012-10-09T14:12:15 (imported from GitLab project)
By Administrator on 2012-10-09T14:12:15 (imported from GitLab)
