Posterous theme by Cory Watilo

Dumping MySQL to import into a new Spree instance

It seems every time I try to upgrade my Spree instance, it never goes right. It always boils down to migrations that don’t work, which is probably my fault since I’m sure I borked something about the migrations and schema at one point.

Last time I upgraded, I thought for sure I’d fixed it however. I did a new store from the ground up and imported all of my db info, fixing it manually where the schema had been modified. It worked for a good while as 0.70, then the upgrade to 1.1 came up.

Because it was such a large upgrade, it actually had to be performed in two steps, first to 1.0 and 1.1. So I correct my earlier statement in one case: the 0.70 to 1.0 upgrade went off without a hitch, migrations and all. Imagine how happy I was.

However, 1.1 bombed miserably. I ended up with failed migrations on the last step, the (now optional) product_groups migration. Suffice to say I learned a little better this time, now using the rake db:migrate:redo command to undo and redo the trouble migrations. Theoretically this should have taken care of the other considerations wrt schema.rb and who knows what else gets modified by rake db:migrate.

However, once the migrations seemed happy and the server started up, the index paged errored out with a message like “Association not found ‘images’”. I have no idea what this means.

To see if there were something wrong with my environment, I installed a spanking-new Spree 1.1, which worked grandly.

So, not knowing what else to do, I’m back to my method of creating a new store that’s known to work and finding a way to manually import my data into the new schema, making any necessary fixes manually. Here’s keeping my fingers crossed.

Which brings me to the point at hand, which is that I forgot to post the magic mysqldump command that let me do the database import in the first place.

It’s: mysqldump -u [user] -c -t [database] > [output file]

The -t is for “no-create-info”, which tells it not to include the table drops and creates that are in a normal sqldump. Since I’m importing into a database already set up by the new instance, I want to use its schemas, not the old db’s.

The -c is for “complete-insert”, which tells it to include column names in the INSERT statements. Since the new schema may (read: will) have new columns, the positional insert which implies the columns will not usually work. This method forces the values into the proper columns, and hopefully the column values not addressed will be ok as NULLs. Obviously, this will not be the case 100% of the time, but so far so good.

So basically, I dump the old db with this command, attempt to import it into the new db which was set up by the new store, look for errors and then fix them manually. Errors tend to crop up around table renames and unacceptable NULLs.

Put a miniature, actively-updated version of a window on top of other windows

http://www.klopfenstein.net/lorenz.aspx/ontopreplica

I've seen this before, but this program has really come a long way since then.

I've recently started following an irc channel (#spree on FreeNode), and I like to see the relatively infrequent updates, but it's a pain to keep remembering to switch to the window.  By the time I do, there's no chance to participate.

I vaguely remembered a program that would let me make a miniaturized version of a window that would stay on top of the others and actively keep pace with the content of the original window.  I couldn't remember the name though, and had a hard time getting google to understand what I wanted (a frequent complaint when trying to search for window-related software in Windows, imagine that).

Finally I found a cousin to the program I was thinking of (don't remember the original, but it was different).  I'd also seen this cousin at that time, but wasn't impressed enough with either of them to keep one.

This time around, though, it looks like this is a fairly mature implementation, with lots of useful options (opacity, sizing, storable settings, region selection, click-forwarding, etc).  It's now showing me just the bottom of the irc window where new comments show up.  It's at 50% opacity and 1:1 size so the text is completely legible.  Even better than miniaturized.

A quick search at alternativeto.net showed that the only other well-known option is a Mac program, so I don't know what happened to the other cousin, but I'm not worried.

You can't get the installer from codeplex (just the executable), so get it from the main site linked here.

Getting the rmagick gem to build on Linux Mint 12 with RVM

I'm using RVM on Linux Mint 12 to run a Spree Commerce development server.

I had previously gotten it working on another Mint box, but I forgot the secret sauce to get the rmagick gem, a dependency of Spree, to build on the machine.

You have to install the libmagick9-dev library with the command "sudo apt-get install libmagick9-dev".  Otherwise you just get an error about not being able to find "Magick-config".

How to turn off message Your current security settings put your computer at risk Click here to change setting? | SpinSafe

http://spinsafe.com/2011/09/30/how-to-turn-off-message-your-current-security-settings-put-your-computer-at-risk-click-here-to-change-setting/

-- Shared with Google Share Button

If you have the Home Premium edition and you turn off the downloaded file prompting before running in Windows, IE keeps telling you how your settings are unsafe.  In business editions you can use gpedit to turn that off, but not in Home.  Here's the registry setting to turn it off in Home.

Twig's Tech Tips: Windows 7: Disable the "Open File Security Warning" message

http://twigstechtips.blogspot.com/2009/08/windows-7-disable-file-security-warning.html

-- Shared with Google Share Button

Since I use SuRun, I get an administrative prompt whenever a program needs to run with elevated privileges.  In addition to that, when I run something that I downloaded from the Internet, I always get the "Are you sure you want to run this downloaded file?" prompt as well, making two prompts I have to navigate.  Since the elevation one is the important one, I used this article to turn off the download prompt.

My Favorite Registry Settings

  1. HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
  2. HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  3. HKEYLOCALMACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
  4. HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont

Adding alternate Ruby installs to DevKit with pik

Actually, pik doesn't have anything to do it, but you'd need pik to manage multiple Ruby installs on Windows, so it's probably in the picture.

There's a pik command that mentions DevKit, but for whatever reason it's not really documented.

That's ok, because you don't need it. Instead, just go to your DevKit directory and edit the file config.yml. Add your Ruby's path on its own line at the end of the file, matching the format of the line above it.

Then go to a command-line and run ruby dk.rb install. That should be it.

Managing multiple Ruby environments with pik

In my last post, I talked about using git to distribute the same ruby environment from production to development in order to make sure the code that works in development is more assured of working in production as well.

However, this might normally constrain you to only using one ruby environment on your development machine (the production one), which is a real constraint. Especially when it comes to evaluating whether to upgrade to the latest Spree code, for example, you might need an entirely different environment. Using git to try to swap back and forth between two or more ruby environments is not a good solution, since you don't want your private ruby environment to pollute the repository, and you probably want the two (or more) to exist alongside each other for the long term.

Unix users have RVM to handle this. Pik is a Windows alternative endorsed by the RVM developers.

You can install pik by following the directions in this post. Pik can then switch between different installed ruby environments with a single shell command.

Normally, you may manage different ruby versions with pik. You install the Ruby versions as usual, side-by-side, by using something like the Ruby installer. Each environment will contain an entirely different set of gems, so you can install two different versions of rails, for example, without any conflict and without it touching your golden production environment.

You should probably only have one instance on your path at a time. Pik will manage this when you switch environments.

Once installed, you run a pik command to add them to your list of environments. You can even add two rubies of the same version. You'll get a warning and be asked for a short name since normally it collapses the version number into a short name, which would cause a conflict when using two rubies of the same version.

Use the pik add [location] command to add different ruby environments to the list of available ones.

Use pik switch [shortname] to switch to an alternate ruby environment. Use ruby -v and/or rails -v to check that your environment.

Use pik default to switch back to your default ruby environment.

Managing Production and Development Ruby Environments with Git

This is an experiment for the most part, but due to blog postings such as this one, I'm led to believe that you can manage and distribute a particular Ruby environment by using Git.

While the idea of distributing an application via Git might seem at odds with Windows' application management (MSI's, Programs and Features Control Panel), it's believable that it might well be possible with applications such as Ruby, which aren't tightly coupled with Windows in the first place. Ruby is primarily developed for a Unix environment in the first place, and although there is Windows integration via RubyInstaller, there really isn't anything in the package itself that expects more than a working shell environment. I'm guessing that RubyInstaller does little to Ruby itself, instead just wrapping with an installer and uninstaller and offering to add Ruby to your path and associate files with the executable.

Putting binaries under version control is usually another point of contention, but that shouldn't be a problem either as long as we're talking about a uniform Windows environments. The Ruby executables installed in one environment should work fine whether distributed to XP, 7, 2003 or 2008. The only relevant distinction should be the 32- or 64-bitness. That leaves the rest of the files, which are primarily the installed gems and any native files they rely on. Again, the bitness is the only issue there. Since the gem files are primarily source code, version control makes fine sense there.

So I'm giving it a shot.

What's the point of doing this? Just as important as the code used for our Spree store is the Ruby environment that runs it. If either break, the store won't run. And we don't sell. And we don't eat. The source code for the store is guarded jealously with Git. Why shouldn't the Ruby environment as well be guarded so?

While that's an important reason to consider using Git on the Ruby environment, that goal can be accomplished via other means (backups, shadow copies). However, running shadow copies on the system drive poses some issues of its own. We only really want to track one relatively-unchanging folder, but shadow copies will track the many automatic system changes that occur as well. This might argue that the Ruby install should be moved to another directory, but that's a different discussion. Backups are difficult to set up and aren't always done, even though they should be. Again, another discussion.

However, there's another purpose which suits version control that isn't taken care of by the other solutions to the backup issue. That purpose is synchronization of the development environment. While the developer may develop and test, thinking that his installation exactly matches what will be used in the final production environment, that assumption is easier said than done. Even if you install exactly the same packages in production and development, there is inevitable drift as experiments are tried, upgrade processes face and resolve issues, and mistakes are made with installs. Git provides a way to mirror the production environment to any developer in a consistent way.

So I'm creating a github repository for the Ruby install on Mojo-a, which I will clone to my development machine and use when testing code which is intended for deployment.

I'll be writing another post on how to manage this environment side-by-side with the other Ruby environments I also want to be able to use on my development machine.

Using sp_change_users_login ‘auto_fix’ to fix user/login

http://rainstorms.me.uk/blog/2010/02/21/using-sp_change_users_login-auto_fix-to-fix-userlogin/

-- Shared with Google Share Button

When moving a database between sql servers, the login information for the server is not included in the move.  This results in databases that have users defined but no associated logins, making them orphans.

This article details a stored procedure to fix the issue, "sp_change_users_login 'auto_fix', 'username'"