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.
If you have tables, keys, and columns that don’t follow the Rails naming
conventions, have a complex database schema, want a DRY ORM solution for
your Ruby desktop app (as well as your Rails web app), and performance
and flexibility are important to you…Check out DrySQL.
Could you contrast the features of DrySQL against Dr. Nic’s Magic
Models? I’m confused about what differences there are, if any. Can they
be used together? Should they?
Could you contrast the features of DrySQL against Dr. Nic’s Magic
Models? I’m confused about what differences there are, if any. Can they
be used together? Should they?
Sorry I didn’t make this more clear…I suppose the differences
immediately stand out for me because I use DrySQL against legacy
databases, and primarily in Ruby apps that are not Rails web apps
(DrySQL does support Rails web apps, though).
On the RubyForge homepage (http://drysql.rubyforge.org) there is a
section titled “DrySQL: Overview of Features” that outlines 6 main
features, none of which (to my knowledge) is provided by Magic Models.
The main difference is that the implementation of DrySQL makes ORM truly
DRY. Everything is generated based on your DB’s information schema, so
you are not constrained in any way by naming conventions (i.e. foreign
key names, primary key names, table names, etc).
A short answer to your question is that DrySQL takes a different
approach to the features of Magic Models, and offers a number of new
features as well. Magic Models is an excellent piece of work, but
unfortunately it did not do what I needed it to do
For a better/clearer explanation, you may want to check out the exmaples
on the DrySQL RubyForge home page, and if you have any more questions
I’ll be happy to answer them
The main difference is that the implementation of DrySQL makes ORM truly
DRY. Everything is generated based on your DB’s information schema, so
you are not constrained in any way by naming conventions (i.e. foreign
key names, primary key names, table names, etc).
Awesome. I work for a company where the philosophy is that you build a
good database schema first - designed so that it can outlive whatever
app server you use to create interfaces. Spoiled by PostgreSQL, I
suppose. No matter what, we’re going to enforce constraints and
relations in the database - so to have a layer that’ll keep us from
having to repeat ourselves in model definitions would be perfect.
One idea - with another ORM wrapper (Alzabo - www.alzabo.org) I used
PostgreSQL comment fields to specify more advanced field attributes. The
idea of using comments in your database to specify more detailed column
information makes a lot of sense to me.
Here I was all exicted till I got to the bottom of the page and didn’t
see
MS SQL Server included.
It was almost an immediate answer to my problem.
Stuart
Adding SQL Server support will not be difficult. Most of the code in
DrySQL is database agnostic. I will just need to create an extension to
the existing sqlserver Rails adapter that implements DrySQL’s
AbstractAdapter interface.
It wouldn’t be unreasonable to say that I could implement support for
SQL Server in the next couple of weeks if I can get my hands on a copy
of SQL Server for testing.
Here I was all exicted till I got to the bottom of the page and didn’t
see
MS SQL Server included.
It was almost an immediate answer to my problem.
Stuart
app server you use to create interfaces. Spoiled by PostgreSQL, I
–
SQL Server in the next couple of weeks if I can get my hands on a copy
of SQL Server for testing.
Is Oracle support in the works? This seems perfect for me, but alas, no
Oracle support.
Yes, I do plan to add Oracle support, along with DB2 and SQL Server.
With luck this functionality will be released in the next month. I’ll
keep you posted
Adding SQL Server support will not be difficult. Most of the code in
DrySQL is database agnostic. I will just need to create an extension to
the existing sqlserver Rails adapter that implements DrySQL’s
AbstractAdapter interface.
It wouldn’t be unreasonable to say that I could implement support for
SQL Server in the next couple of weeks if I can get my hands on a copy
of SQL Server for testing.
Yep, count this as another vote for SQLite - I’m really getting to
like it for apps where there’s not a huge amount of data and I just
need a DB that works…
I see no reason why not. I haven’t used DrySQL, but looking at what
it does, it should work with scaffolding_extensions. Try it and
report back to the list.
Can I use it with scaffolding_extension ? I have a very complex legacy
project I have mapped out quite nicely in ActiveRecord, and uses
scaffolding_extensions. I’d like to add DRYSql to it even though it
likely isn;t needed, just to start using it, but only want to do it if
there;s not a ton of work to be done (because it works now, as is, but,
of course, I;d like to learn a faster, simpler way!) Thanks.
Can I use it with scaffolding_extension ? I have a very complex legacy
project I have mapped out quite nicely in ActiveRecord, and uses
scaffolding_extensions. I’d like to add DRYSql to it even though it
likely isn;t needed, just to start using it, but only want to do it if
there;s not a ton of work to be done (because it works now, as is, but,
of course, I;d like to learn a faster, simpler way!) Thanks.
Yes, DrySQL should be compatible with scaffolding_extension.
DrySQL is simply a collection of extensions to the existing modules and
classes in ActiveRecord, and should be compatible with any plug-ins that
are compatible with ActiveRecord.
If anybody does happen to come across a plug-in that DrySQL does not
play nice with, please let me know and I will address it.
I’m getting requests, suggestions, etc from a bunch of different
channels, and am trying to make the DrySQL RubyForge forums the central
home for these discussions.