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?
Kevin Williams wrote: > 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
Bryan Evans wrote: > 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
On 11/7/06, Daniel Collis-puro <rails-mailing-l...@andreas-s.net> wrote:
> Bryan Evans wrote: > > 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.
Stuart Fellowes wrote: > 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
> On 11/7/06, Daniel Collis-puro <rails-mailing-l...@andreas-s.net> wrote: >> app server you use to create interfaces. Spoiled by PostgreSQL, I
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.
> Stuart Fellowes wrote: > > 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
> > On 11/7/06, Daniel Collis-puro <rails-mailing-l...@andreas-s.net> wrote: > >> app server you use to create interfaces. Spoiled by PostgreSQL, I
> 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.
From: rubyonrails-talk@googlegroups.com [mailto:rubyonrails-talk@googlegroups.com] On Behalf Of Dark Ambient Sent: Tuesday, November 07, 2006 9:35 PM To: rubyonrails-talk@googlegroups.com Subject: [Rails] Re: [ANN] DrySQL
Bryan, I wish I could help but have no access (no pun intended) to SQL Server. Please let us know though when you add the support.
Thanks Stuart
On 11/7/06, Bryan Evans <rails-mailing-l...@andreas-s.net> wrote:
Stuart Fellowes wrote: > 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
> On 11/7/06, Daniel Collis-puro <rails-mailing-l...@andreas-s.net> wrote: >> app server you use to create interfaces. Spoiled by PostgreSQL, I
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.
Sam wrote: > 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
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...
> Bryan Evans wrote: > > ATTN: Stuart and other SQL Server users...
> > DrySQL now supports SQL Server! > > (as of version 0.1.3)
> > It has been tested only against SQL Server Express 2005, but should work > > with any version of SQL Server that offers the information_schema views.
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.
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.
Ike wrote: > 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.
Two requests: 1. Is there a way to enable it only for certain models? (Let me use it on my legacy models, for instance, and keep my new models without it.)
2. How 'bout an option to generate the required code to stdout, instead of just running it. So I could do:
puts LegacyModel.dry_sql_code
and get: "set_primary_key 'lm_id'\n" "belongs_to :xyz" etc.
Useful for debugging, learning, and when you still want to retain control (I have something similar to this in a rake script)
> Two requests: > 1. Is there a way to enable it only for certain models? (Let me use it > on my legacy models, for instance, and keep my new models without it.)
> 2. How 'bout an option to generate the required code to stdout, instead > of just running it. So I could do:
> puts LegacyModel.dry_sql_code
> and get: > "set_primary_key 'lm_id'\n" > "belongs_to :xyz" > etc.
> Useful for debugging, learning, and when you still want to retain > control (I have something similar to this in a rake script)
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.
