Rails plugins and libraries / Database-level

From WhyNotWiki

Jump to: navigation, search

Contents

[edit] [ActiveRecord/database-level (category)]

[edit] ActiveWarehouse

http://activewarehouse.rubyforge.org/

[edit] Appable plugins: distribute models in your plugin

See Rails plugins and libraries / Plugin tools#Appable plugins

[edit] redhillonrails_core

http://www.redhillconsulting.com.au/rails_plugins.html

http://www.redhillconsulting.com.au/rails_plugins.html#redhillonrails_core

The plugin provides two mechanisms for adding foreign keys as well as preserving foreign keys when performing a schema dump.
t.foreign_key :customer_id, :customers, :id

[edit] ActiveRecord Defaults

http://rubyfurnace.com/plugins/activerecord_defaults

Allow you to easily specify default values for attributes on new model objects.

How does this compare to having the defaults stored in the database?



[edit] [ActiveRecord/database-level (category)]: Migrations

[edit] Migrate "development" and "test" databases simultaneously

[edit] When would you not want to?

I've had numerous occasions where I wonder why my test isn't passing, only to eventually find out that I hadn't migrated the test database yet, only development. I had done manual testing with the development environment, and everything had worked beautifully, so I was mystified why it wouldn't work in test.

[edit] (The plugin)

[To do: Soon to be released]



[edit] star_full.gif star_full.gif star_full.gif Transactional Migrations

Homepage: http://www.redhillonrails.org/#transactional_migrations
Source code: svn://rubyforge.org/var/svn/redhillonrails/trunk/vendor/plugins/transactional_migrations



Description: Transactional Migrations is a plugin that ensures your migration scripts—both up and down—run within a transaction. When used in conjunction with a database that supports transactional Data Definition Language (DDL)—such as PostgreSQL—this ensures that if any statement within your migration script fails, the entire script is rolled back.


License: [[:MIT license|MIT license]]


Authors: Red Hills Consulting 


rake db:migrate:plugins # Migrates both acts_as_bunny and acts_as_chicken
rake db:migrate:plugins PLUGIN=acts_as_bunny
rake db:migrate:plugins PLUGIN=acts_as_bunny VERSION=2

[edit] star_full.gif star_full.gif star_empty.gif Plugin migrations

Homepage: http://wiki.pluginaweek.org/Plugin_migrations
Documentation: Readme
Source code: script/plugin install -x http://svn.pluginaweek.org/trunk/plugins/active_record/migrations/plugin_migrations
Project/Development: http://dev.pluginaweek.org/browser/trunk/plugins/active_record/migrations/plugin_migrations
As listed in other directories: http://rubyfurnace.com/plugins/plugin_migrations
Description: plugin_migrations adds the abilities for all plugins to have the same migration capabilities that your Rails application has. It does this by adding a new table called plugin_schema_info to keep track of the migration version of each plugin.





[edit] Installation

script/plugin install -x http://svn.pluginaweek.org/trunk/plugins/rails/loaded_plugins/
script/plugin install -x http://svn.pluginaweek.org/trunk/plugins/active_record/migrations/plugin_migrations

[edit] Usage

Just create a db/migrate directory within your plugin's directory and throw some plugin-specific migrations (creating tables, most likely) in it and you're set!

Then when the user installs your plugin, they can simply run rake db:migrate:plugins to run those migrations!

(Much better than creating a migration generator, I think.)

rake db:migrate:plugins
rake db:migrate:plugins # Migrates all loaded plugins
rake db:migrate:plugins PLUGIN=acts_as_commentable
rake db:migrate:plugins PLUGIN=acts_as_commentable VERSION=2


[edit] star_full.gif star_empty.gif star_empty.gif DSL-style migrations

Makes your migrations a little DRYer.

http://habtm.com/articles/2006/12/26/dsl-style-migration

class CreateAccounts < Special::Migrations::Table
  table_name :accounts
  column     :login,      :string
  column     :email,      :string
  column     :created_at, :datetime
  options[:force] = true
end

Pope Says: December 26th, 2006 at 07:10 AM

as for maintainable, it may not in the area you are thinking about. Since going down is just the opposite of going up, why try to make sure that you keep those two in sync? I have run into situations where going down broke something, most of the time due to a typo or because something was forgotten. Since this seems to look like it takes care of that, it becomes one less thing you have to maintain.

I can see a complaint with it that it may be too customized. I have fallen in this pitfall of metaprogramming where i get so into it, that it becomes less readable. That is because this way of thinking about migrations solves the majority of the problems; however, for some of the other problems, a user would have to resort back to using the old system. That means that someone using this would have to be familiar with both ways to do it.

That problem now falls on the user of this special system as to if he/she wants to use it or not.

David Says: December 26th, 2006 at 08:39 PM

> I usually rewrite migration files and remigrate database via > VERSION=0 again and again.

Yeah, I do this a lot during initial development, so maintainability does count.

Jason Says: December 28th, 2006 at 12:43 AM

Wow, you guys really take the DRY concept way too far. DRY is nice and it’s one of the reasons I love rails but come on, “redundant temporary variable ‘t’ in ‘create_table’ block”? That’s just silly.

[edit] star_full.gif star_empty.gif star_empty.gif Migratory Shortcuts

Migrations are truly a great addition to Rails. That said, if you have a boat load of tables in your project it can be pretty tedious to keep repeating the same values [column specifications] again and again.

Somewhere in the middle of doing this…

create_table :actors do |t|
  t.column "created_at", :datetime
  t.column "updated_at", :datetime
  t.column "deleted", :boolean, :null => false, :default => false
end

create_table :names do |t|
  t.column "name", :string, :null => false
  t.column "created_at", :datetime
  t.column "updated_at", :datetime
  t.column "created_by", :integer, :null => false
  t.column "updated_by", :integer, :null => false
  t.column "deleted", :boolean, :null => false, :default => false
end

create_table :actors_names do |t|
  t.column "actor_id", :integer, :null => false
  t.column "name_id", :integer, :null => false
  t.column "position", :integer, :null => false, :default => 0
  t.column "created_at", :datetime
  t.column "updated_at", :datetime
  t.column "created_by", :integer, :null => false
  t.column "updated_by", :integer, :null => false
  t.column "deleted", :boolean, :null => false, :default => false
end

for the tenth time, you begin to wonder if there is a better way.

Introducing.. a better way.

The above becomes this…

create_table :actors, :with => [:timestamps,:userstamps,:acts_as_paranoid]

create_table :names, :with => [:timestamps,:userstamps,:acts_as_paranoid] do |t|
    t.column "name", :string, :null => false
end

create_link_table :actors, :names, :with =>
    [:timestamps, :userstamps, :acts_as_paranoid, :acts_as_list]

This makes dealing with migrations just a bit more manageable, and you no longer need to remember all the “magic” column names. Just say “acts_as_list” and the “position” column is added for you.

Thus far the following options are supported:

  • acts_as_list
  • acts_as_tree
  • acts_as_nested_set
  • acts_as_paranoid
  • timestamps
  • userstamps


[edit] subverted_migrations

http://rubyfurnace.com/plugins/subverted_migrations

This plugin makes it easier to use Rails migrations with Subversion (when working with multiple branches).

It has two main features:

  • Ensures unique version numbers across the trunk and branches
  • Keeps track of which migrations have been applied to the database, and applies new migrations when merged in to the branch.

[edit] [ActiveRecord/database-level (category)]: [Searching (category)] / query building

See also Ruby libraries#Database

[edit] acts_as_locateable

Categories/Tags: [searching (category)][acts_as_plugins (category)]
Homepage: http://www.baconbear.com/articles/2006/12/29/actsaslocateable-released
Source code: http://svn.baconbear.com/rails_plugins/acts_as_locateable/trunk/


As listed in other directories: http://rubyfurnace.com/plugins/actsaslocateable
Description: [[description := ActsAsLocateable is an easy way to give any model the ability to be found by location.[1]|ActsAsLocateable is an easy way to give any model the ability to be found by location.[2]]]





http://www.baconbear.com/articles/2006/12/29/actsaslocateable-released

ActsAsLocateable is an easy way to give any model the ability to be found by location. For instance, say you have a model Store which is associated with a zip code indicating where that Store is located. To find all the stores within a specific radius of another ZipCode, you can do a

Store.find_within_radius(10, 12345) # Find all stores within 10 miles of zip code 12345

Based on: the ZipCodeSearch plugin (heavily)


[edit] ZipCodeSearch

Categories/Tags: [searching (category)]
Homepage: http://zipcodesearch.rubyforge.org/
Source code: svn://rubyforge.org/var/svn/zipcodesearch/trunk


As listed in other directories: http://rubyfurnace.com/plugins/zipcodesearch






http://zipcodesearch.rubyforge.org/

ZipCodeSearch is a Rails plugin that makes implementing location-based searches a cinch. If you've ever wondered how to do location-based radius searches in your snazzy new Web 2.0 application, then this plugin might save you some time.

This plugin will create a ZipCode model, which contains all the code for calculating distances and searching. This plugin will also create a migration that adds a zip code table to your database, complete with 45,000 zip codes and with their lat/lon and city/state information. Finally, this plugin will generate a fully functional controller/view that contains a simple example of how to use the ZipCode model for your location searches.

[edit] star_full.gif star_full.gif star_full.gif ez-where [DSLs (category)]

Very intuitive.

A couple neat examples (http://brainspl.at/articles/tag/where):

    options = Article.find_where_options do |article|
      article.comments.user.name == 'Fab'
      article.and( (article.c.title =~ 'A%') | (article.c.title =~ 'B%') )
      article.comments.any do 
        body =~ 'Lorem%'
        body =~ 'Ipsum%'
      end
    end

cond = c{ title =~ '%ruby%' }
cond += c{ description =~ '%ez-where%' }
cond |= c{ user_id === (1..5) }
cond -= c{ pub_date > Time.now.to_s(:db) }
Post.find :all, :conditions => cond
=> ["((title LIKE ?) AND (description LIKE ?)) 
    OR ((user_id IN (?)) AND NOT (pub_date > ?))",
    "%ruby%", "%ez-where%", [1, 2, 3, 4, 5], "2006-06-21 01:17:47

http://brainspl.at/articles/2006/01/30/i-have-been-busy

./script/plugin install http://opensvn.csie.org/ezra/rails/plugins/dev/ez_where/

http://rubyforge.org/projects/ez-where/

ez-where tag on Ezra's blog

[edit] star_full.gif star_full.gif star_full.gif CriteriaQuery [DSLs (category)]

Description [3]:

CriteriaQuery is an extension to the ActiveRecord find mechanism. It allows object-oriented construction of queries.

Examples: [4]

Person.query.name_like(‘name’).join(‘address’).city_like(‘city’).join(‘state’).name_eq(‘state’)

instead of

Person.find(:all, :conditions=>[‘people.name LIKE ? AND addresses.city LIKE ? AND states.name=?’, ‘name’, ‘city’, ‘state’], :include=>[:city=>[:state]])

[5]

 pq = Person.query
 pq.name_like('name')
 pq.join('address') do |address|
   address.or do |streets|
     streets.street_1_like('street).street_2_like('street)
   end
 end

 pq = Person.query
 pq.join(:lives_in)
 pq.join(:works_in)
 pq.or << pq.lives_in.street_eq('some_street') << pq.works_in.street_eq('some_street')

Features:

  • Available expressions:
    • Equals
    • Not equal
    • Like
    • Greater than
    • Greater than or equal
    • Less than
    • Less than or equal
    • Is null
    • Not null
    • In
  • Available subrestrictions
    • Disjunction (OR)
    • Conjunction (AND)
    • Negation
  • Supports joins across multiple associations
  • Supports joining the same table multiple times

[edit] acts_as_solr

Categories/Tags: [full-text search (category)][acts_as plugins (category)]
Homepage: http://acts-as-solr.rubyforge.org/
Source code: http://opensvn.csie.org/thiago/rails/plugins/acts_as_solr/


As listed in other directories: http://rubyfurnace.com/plugins/acts_as_solr






http://rubyfurnace.com/plugins/acts_as_solr:

This plugin adds full text search capabilities using Solr to any Rails model.

[edit] Live search

(very "cool"!)

http://www.recentrambles.com/pragmatic/view/59

[edit] Query by example

http://blog.codahale.com/2006/02/04/a-rails-howto-query-by-example/

[edit] Squirrel

http://giantrobots.thoughtbot.com/2006/9/29/an-improvement-for-querying-in-rails

[edit] Query builder

http://rubyfurnace.com/plugins/query_builder

This plugin enables you to define finder methods that bypass the overhead of construct_finder_sql.

Inside an ActiveRecord model definition,

define_finder query_name, query_type, options_hash

will create a SQL query method called query_name from a given options_hash. query_type can be :first or :all.

The plugin supports all options except :include, but ignores with_scope options.

Example:

class Recipe
  define_finder :find_all_of_user, :all,
                     :conditions => 'user = :user AND priv < :priv'
end

This defines a query method which can be called like so:

Recipe.find_all_of_user :user => 'martin', :priv => 1

This call is equivalent to

Recipe.find :all, :conditions =>
         ['user = :user AND priv < :priv', {:user => 'martin', :priv => 1}]


[edit] star_full.gif star_empty.gif star_empty.gif Condition Builder

http://rubyfurnace.com/plugins/condition_builder

Book.find(:all,
  :include => {:content_pointer => :invitees},
  :conditions => Condition.block { |c|
    c.and "invitees.user_id", self.id
    c.and "content_pointers.created_by_id", self.id
    c.and "content_pointers.company_id", company.id if company
  })

[edit] conditioner

http://www.bigbold.com/snippets/posts/show/2510

Converts arrays of this form:

[['user_id', 3], ['job_id', 4]

into ActiveRecord conditions form:

["user_id=? AND job_id=?", 3, 4]

[edit] SodaSearch

Homepage: http://sodasearch.rubyforge.org/
Source code: svn://rubyforge.org/var/svn/sodasearch
Project/Development: http://rubyforge.org/projects/sodasearch/


Description: SodaSearch is a drop-in full text indexer plugin for Ruby on Rails. It allows coders to add full text indexing to their models with minimal effort. The index is stored as two regular tables in your project's existing RDBMS.





Soda Search is a medium-performance full-text indexing system. It is loosely based on the same principles as Xapian (www.xapian.org/).

The system is relatively simple. It consists of two database tables per class being indexed, plus some ActiveRecord extensions shared by all classes that use the Indexer.

The database tables are deliberately NOT normalized completely, to cut back on the computational overhead required to do searches and updates.

This system is quite useable as it is, but the index format it provides is also the foundation for a much more robust searching system. We will eventually implement phrase matching, term weighting, Boolean term combination, etc. This can all be accomplished with the current index format; all that needs to be done is modify the searching code.

Facts about Rails plugins and libraries / Database-levelRDF feed
Description [Oops! No type defined for attribute]
Retrieved from "http://whynotwiki.com/Rails_plugins_and_libraries_/_Database-level"
Personal tools