Recently we moved our application from rails 2.3.11 to rails 3.0.7, after everything was done we saw a weird issue. Whenever we generate a migration, the number is auto incrementing where as we needed migration number in UTC timestamp. Since there are 5 members in our team, its causing very big problem.
Kindly help me to resolve this issue.
Set config.active_record.timestamped_migrations = true in your config/application.rb
Related
We have always had some issues with rails schema file. It got worse after upgraded from rails 3 to rails 4.2. So everytime someone runs "db: migrate" on the local machine, it adds, removes or edit stuff in the schema file. Nothing got affected in the database though.
When we were on Rails3, we got changes like string limit: 255 changes to 100, columns removed and added back in a different row. In Rails 4, apart from the pre-existing ones, we got all the timestamp (created_at, updated_at) added with null: false. We don't set up the default for timestamp in migration files. Also, the index names are changed to those rails generated ones, but we do specify the index names and they are sitting in the database without any issue.
Now it gets really annoying as it causes conflicts on and making noise. Any suggestion to fix this?
User Rails 4.2.10, Ruby 2.5.3, mysql version 5.7.22 by Homebrew.
Has anyone come across a situation where they are unable to start a Sitefinity site due to this error
The database schema version (6421) is higher than the running Sitefinity version (6410). Downgrade is not allowed
I've searched for a decent answer but I haven't been able to find one yet. Any help would be good.
It means that you ran build 6421 on this database (and possibly upgaded it). Now you are trying to run a lower build 6410, which is not allowed by default.
You can override this behavior by setting ignoreDowngradeExceptions="true" on the connection string, although you should be careful with using this approach on a production environment.
In case of these two builds, overriding the default behavior will most probably not be a problem because they both belong to the same Sitefinity version (10.0), so there should be no schema changes between them.
It would be a problem though, if you try to run a 9.2 build on a 10.0 database.
I know its late. Maybe still can help someone else. Execute this query. Its works for me.
update [DB_NAME].[dbo].[sf_schema_vrsns]
set version_number = 6410
where version_number = 6421
update [DB_NAME].[dbo].[sf_schema_vrsns]
set [assembly] = REPLACE([assembly],'10.0.6421.0','10.0.6410.0')
where [assembly] like '%10.0.6421.0%';
I'm having a problem with an existing Mojolicous app. I have added some new routes, views, controllers, and models, and am returning database results to view using Rose::DB::Object ORM.
I updated the production version today with code that had been working great on Morbo. But, on apache2/plack/psgi mod_perl config the new Models are only returning the queries about 1 in 5 sometimes 1 in 10 times.
I've eliminated a number of variables, like I can query the database directly and get my results no problem. Older Model's and their queries always work.
It appears that only this new functionality is intermittent. I have narrowed requests to only one server and have restarted apache. But, am now at the point that I don't understand why the issue is persisting.
I think this is some kind of mod_perl wonky behavior, but don't know why an apache restart doesn't fix it.
Any help or ideas would be awesome.
I did finally resolve this and it turned out to be something simple. I was missing the use statement for my controller in my main application script. The script where I setup the routes. I'm not sure I understand why it was working intermittently in production and working all the time in development. But, once I added:
use TheApp::Controller::Tags; in the main app pm it worked consistently.
In retrospect it feels like I should have figured it out sooner, but the fact that it worked part of the time led me down the wrong path. Hopefully this will help someone else sometime.
In one of our apps db:migrate is not set to automatically run on every deploy to Heroku. It hasn't been Continuously Integrate yet.
We've ran into an issue and for debugging purposes I want to see when a particular migration ran.
Is this possible?
Rails does not give such feature, when you run migration, time_stamp of migration is added in an array , to remember which migration is executed and which is not.
so what you can do is , log in to your database (psql if using postgres) and find created time or updated time of table manually .
this may help you do so https://stackoverflow.com/a/11868687/1970061 .
I'm migrating my application from Rails 3.0.12 to 3.2. I use the active_record_store to work with my session variables, owing the size limits on the default cookie store. On the new version of Rails, however, the session variable is not getting set.
I can see that the cookie session_id is being set with a value, but I can look at the contents of the database and see no values being inserted when a session variable is supposed to be populated.
However, if I switch back to cookie store, it works fine. Is there anything I can check to find out what's going on?
I'm afraid the problem solved itself, perhaps in a Gem update that I performed in preparing to respond to the comments on this question. I had the Rails 3.2 version of my app on a separate Git branch, so I brought it back and merged it with my current development version.... and it all "just works".
I can't help but think this was a transient issue with either an older version of my code or a gem, but it's solved now, so I'll close this question.