# \[ANN\] DrySQL

**URL:** <https://www.ruby-forum.com/t/ann-drysql/75175>\
**Category:** Ruby\
**Created:** [November 8, 2006, 12:20am UTC](https://www.ruby-forum.com/t/ann-drysql/75175 "2006-11-08T00:20:14Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![bsevans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/4da419/32.png) [@bsevans](https://www.ruby-forum.com/u/bsevans)\
**Post date:** [November 8, 2006, 12:20am UTC](https://www.ruby-forum.com/t/ann-drysql/75175/1 "2006-11-08T00:20:14Z")

</div>

If any of you use ActiveRecord for Object-Relational Mapping in your  
Ruby apps, you may find the DrySQL plug-in helpful:  
[http://drysql.rubyforge.org](http://drysql.rubyforge.org)

DrySQL is a plug-in that extends ActiveRecord to provide a complete DRY  
solution for Object-Relational Mapping.

You’ve defined columns, constraints, relationships, and keys on your DB.  
With DrySQL you don’t need to re-define _any_ of these things in your  
Ruby  
code.

DrySQL has received numerous comparisons to Magic Models as both  
projects have a feature in common: automatic generation of associations  
and validations for data objects. The main thing that differentiates  
DrySQL is that the ORM is truly DRY. Your table names, columns names,  
primary & foreign key names do not need to follow any naming  
conventions, because DrySQL retrieves _all_ of this information from  
your DB’s information schema. By using the information schema to its  
full potential, you don’t need to re-define _any_ artifact of your DB  
schema in your application code.

In the worst-case scenario (your table name does not conform to  
ActiveRecord naming conventions), your data class could look like this:

class Employee \< ActiveRecord::Base  
set\_table\_name “EMPLOY01”  
end

You never need to explicitly identify primary/foreign keys, or specify  
associations or validations in your application code (if your table name  
conforms to AR naming conventions, you don’t even need to define a class  
for it). The end result is that you don’t need ORM code in your  
application and you gain loose coupling to your database structure: you  
can change your tables/columns/constraints on your DB and not need to  
change your application code.

In addition to taking a different approach to solving the  
“auto-generation of associations and validations” problem, DrySQL  
introduces a number of “new” features as well.

I’m not going to try to sell you on DrySQL if you’re happy with your  
current Ruby ORM solution, but if your current solution doesn’t meet  
your needs then please do check out DrySQL:

[http://drysql.rubyforge.org](http://drysql.rubyforge.org)

Cheers.  
…And sorry for the long-winded post. Hopefully some of you find it  
useful

- Bryan