[Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case)

Rob Pitt rob at motionpath.com
Fri Feb 17 11:56:58 EST 2006

This script was tested on a project with many thousands of join
relations involving multiple STI classes.

Here is a command-line script (and steps for use below, please read if
you use this) that you can run from the command line that *should*
auto-magically migrate a project from an old join table system to the
new one (with any store - it's pure Og calls.) 

Do apologise for the messy hackishness but it's only for one-off

If loading rubygems would interfere with your setup somehow you will
need to remove require 'rubygems' from right at the top of the script
(most people will need it).

Help information (can be obtained by running the script with no

Exports or imports the join data for a Nitro application
(Works with glycerin as of date 17/02/2006)

Usage: ./join-table-migrator.rb <[-i] [-e]>
"</path/to/run_script_for_nitro_project>" "<dump_file>"

Export example (exports data from run.rb in curent directory to
  ./join-table-migrator.rb -e ./run.rb dump.bin

Import example (Imports data from dump.bin to run.rb in current
  ./join-table-migrator.rb -i ./run.rb dump.bin

Steps to use:

1. Open a console window in the directory of your project.

2. Export data from a project ***BEFORE*** applying the patches (use
darcs unpull to remove them if you have already applied them), i.e.:

./join-table-migrator.rb -e ./run.rb dump.bin

3. Apply the patches to your Glycerin repository.

4. Import the data back in again, i.e.
  ./join-table-migrator.rb -i ./run.rb dump.bin

5. Run your project and everything will appear to be the same (unless
you examine the back-end database structure... :P)

If you need to update multiple projects you will have to repeat these
steps again (i.e. unpull the patches with darcs export, re-apply,

- rp

On Fri, 2006-02-17 at 13:20 +0000, Rob Pitt wrote:
> WARNING: This patch causes join tables to be created with different
> names and will require you to manually copy join table data into newly
> named tables if applied to a project you are already using.
> Why would I make a patch that requires this? Not having this requirement
> (i.e. doing it in an automated fashion) would be fairly complicated and
> a big drain on CPU.
> This patch still needs to be implemented at some point because it
> enables a desirable behaviour, and we are at 0.2 so we should make
> changes with big impacts like this now rather than later.
> This is a very minor modification so that a model like this behaves as
> it should:
> Class Article
>   property :title, String
>   joins_many :first_join, Category
>   joins_many :second_join, Category
>   joins_many Category
>   def initialize(title)
>     @title = title
>   end
> end
> Without this patch, items you push into .first_join are visible
> in .second_join and the .categories join (all other combinations of this
> are also true).
> This is wrong, and this patch corrects this.
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
-------------- next part --------------
A non-text attachment was scrubbed...
Name: join-table-migrator.rb.bz2
Type: application/x-bzip
Size: 1866 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060217/e3680972/attachment.bin 

More information about the Nitro-general mailing list