Shrinkfile.example

filter_table :users do |f|

  # filter_by takes a sql condition for the records you would like to keep.
  # This condition can be as a hash or string
  f.filter_by("id % 1000 == 0")

  # sanitize takes a block, yields the fields of each record as a hash of
  # fieldname => value and should return a new set of fields that has been
  # sanitized however desired.
  f.sanitize do |u|
    u[:email] = "somerandomemail#{u[:id]}@foo.bar"
    u
  end

  # filter_subtable indicates a child table to filter based upon the filtering
  # done on this table.
  f.filter_subtable(:favorites, :foreign_key => :user_id)

  # if needbe you can filter by a different key besides the id.  All filtering
  # will be done before all sanitization, so you don't need to worry about if
  # these are getting munged.
  f.filter_subtable(:email_preferences, :foreign_key => :user_email,
                                        :primary_key => :email)

  # You can also pass an additional where clause expression that restricts
  # filtering propagation to certain subset of rows. This allows to support
  # polymorphic relationships, or STI.
  f.filter_subtable(:email_preferences, foreign_key: user_id,
                                        where: "type = 'User::Registered'")

  # 'where' clause can be anything that sequel supports
  f.filter_subtable(:email_preferences, foreign_key: user_id,
                                              where: {  type: 'User::Registered',
                                                       color: 'Red'})

  # If it feels more natural, you can define additional filters
  # within a filter_subtable definitition
  f.filter_subtable(:lockable_table, :foreign_key => :user_id) do |sub|
    sub.filter_by(...)
  end

  # To keep things consistent, if you're sanitizing something that also exists
  # in other places (ie tables aren't fully normalized, and you have email in 2
  # places), you probably need to be able to specify this somehow
  f.sanitize_subtable(:email_preferences,
                      :local_field => :email,
                      :foreign_field => :user_email)

end

# If you have a chain of dependencies, ie users has favorites, favorites has
# some additional set of tables hanging off it, you can define the 2nd
# relationship in its own filter_table block, and the tool will figure out that
# going from users => favorites also implies
# favorites => favorite_related_table
filter_table :favorites do |f|
  f.filter_subtable(:favorite_related_table, :foreign_key => :favorite_id)
end

# You can completely remove a table as well
remove_table :removables