I'm wondering if there's an integrated solution to have a database with versioned records supported by rails (ala version_fu ar_versioned) and a differ thanks!
Check out acts_as_versioned.
Thanks srboisvert for mentioning my fork. Here's a bit more info/context. The updated_attributes column's value is set for each version, and lists what attributes were changed from the prior version. This is useful when you need to display a record/version and want to show what values changed. I needed this to implement a history view for a particular record we had, where we wanted to color any changed values red in each version we displayed in the history. This is covered in my blog post which is linked above, along with a couple other minor tweaks.
If anyone tweaks it further, please do send me a pull request, etc.
As you noted, that functionality is supported in plugins, and won't be supported by Rails core.
There is a forked version of acts-as-versioned (ar-versioned) that includes an additional column in the versioned table (updated-attributes) that is a hash of what was changed.
I ended up using acts_as_audited to accomplish this along with the htmldiff plugin to get some pretty output.
see: diff a ruby string or array
Related
I have to update a table with missing data from an importation. And I don't want paper trail to version this update. How can I skip the versioning for this one time execution without removing has_paper_trail from my model?
I have found the answer:
Model.paper_trail_off!
In latest version, however, you can do it like
PaperTrail.request.disable_model(YourModel)
Official Doc
Working through Hartl's sample_app tutorial...not an issue with the tutorial, but with my own tinkering. Wondering if someone smarter than me can help us all out... I know that often times updating gems can bork your app(s), so I was prepared for this (hooray for committing often!), but when I saw that the bootstrap-sass gem I was using was out-of-date, I had to update.
Before the update, I was using v2.3.2.0 - no ill side effects.
After the update, the gem version was 3.0.2.1 and certain sass variables had changed, which was an easy fix (namely cameCase to non-camel-case). This was easily identified and fixed by running the rspec tests written to this point in the tutorial.
What's throwing me through the loop is now the right top menu links (home, help, sign in) look stacked like a "normal" un-styled un-ordered list. Correspondingly, this is causing the top bar to triple in size, and thus cover some of the text seen in the main content area.
I'm not a talented enough front-end guy to know exactly what is going on, but have tried to describe it as best as I can here. I can point you to the git commit compare here, but even this is a lot to take in.
In the meantime, I've reverted to v2.3.2.0 and all is back to how it was. Lesson learned, sniff out changes and test-test-test before blindly updating gems.
Thanks in advance for any and all help!
P.S. I also have posted this in the /r/Learn_Rails subreddit here.
For a list of what is different between BS 2.x and 3.x see this link: http://getbootstrap.com/getting-started/#migration
If you want to use the latest BS version, you'll have to update the HTML to reflect the new class names etc.
This is happening because of the new functionality introduced in the newer version of Bootstrap(3.0) and tutorial is based on the bootstrap verison(2.3..).
So, If you are interested then see the changes made in the newer versions Click Here
I'm working on a Grails project that is internationalized (using the .properties resource bundles), and at the end of each release, we send a list of all the i18n messages that need to be translated. The problem is, there is no way to know which ones need updating/which ones are missing without manually tagging it (ie adding some 'magic word' at the end of each key). This seems very hacky and error prone.
What is common practice for keeping track of uninternationalized i18n labels?
Thanks.
Missing labels can automatically be detected by the ResouceCheck ant task. In particular, with the cross bundle check, it can inform you if a label is missing from any the properties for any locale.
For updated labels, I generally store the version number of the messages.properties that was last used as translation source in a header comment in each messages_xx.properties. Then a diff between the current messages.properties and the translation source version will show the properties that have changed and need to be retranslated.
I have been working with the latest version of typus(3.0.3) for Ruby on Rails. Setting the path used to be set this way
Typus::Configuration.options[:path_prefix] = 'backoffice'
so that "http://localhost:3000/admin" would become this "http://localhost:3000/backoffice" to gain access to the admin system.
So basically i cant find a way to set this in the new version. Any ideas on how to set this?
Any help would be greatly appreciated...
Sad to say, but it doesn't look like this is possible. I just scanned through the Typus source (branch '3-0-stable') and "admin/" is hardcoded all over the place.
I'm using NetBeans + Rails 2.3.8.
I notice that whenever I generate a model, the migration filename for it includes the date and time:
Model Name: User
Migration File Name : 20100916172053_create_users.rb
But when I see books (like Agile Web Development with Rails), the (rake-generated examples int it) all show simple numbers like 001_create_users, 002_create_sessions etc.
How do I get that simple numbering scheme (it looks neater, easier on the eyes when searching for a model)?
Or is it better to just go with the flow and not bother about what kind of versioning number is used?
You can add this to config/environment.rb
config.active_record.timestamped_migrations = false
Note that the default was changed to timestamps because it (the numbering version) causes problems in multi-developer environments. When two developers both create a migration between source control updates, the migrations will have the same numbers. If you are working alone that would not be a problem.
Also, I'm not sure how it will work if you already have existing migrations, so be careful if that is the case.
The migrations wth the timestamp are the newer form as that allows more than one person at a time to add a migration to the project. This is particularily useful in projects with more than one developer as with the old numbered approach you would need to add the migrations in lock step or renumber them.
So I would recommend that you stick with the timestamp form.
However if you still want to use the older numbered forms you can do as #ngoozeff suggested and add:
config.active_record.timestamped_migrations = false
to either your environment.rb or an initializer.