[ANN] DrySQL

[Bryan Evans]

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.

The official RubyForge homepage is the best source of documentation at
the moment:
http://drysql.rubyforge.org/

My blog also hosts some discussion of implementation:
http://allyourdatabase.blogspot.com/

I'm looking forward to hearing your feedback.
Cheers.

- Bryan

--
Posted via http://www.ruby-forum.com/.

[Kevin Williams]

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?

http://magicmodels.rubyforge.org/

[Bryan Evans]

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?
>
> http://magicmodels.rubyforge.org/

Hi Kevin

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

Cheers.

- Bryan

[Daniel Collis-puro]

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.

You'll from me again, most likely . . .

-DJCP

[Dark Ambient]

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-mai...@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.

You'll from me again, most likely . . .

-DJCP

--
Posted via http://www.ruby-forum.com/.

http://en.wikipedia.org/wiki/Dark_ambient

[Bryan Evans]

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-mai...@andreas-s.net> wrote:
>> app server you use to create interfaces. Spoiled by PostgreSQL, I
>>

>> -DJCP
>>
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>> >
>>
>
>

> --

Hi 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.

[Dark Ambient]

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

--
http://en.wikipedia.org/wiki/Dark_ambient

[Matt Scilipoti]

You all can get free copies of SQl Server Express from http://msdn.microsoft..com/vstudio/express/.

---

From: rubyonra...@googlegroups.com [mailto:rubyonra...@googlegroups.com] On Behalf Of Dark Ambient
Sent: Tuesday, November 07, 2006 9:35 PM
To: rubyonra...@googlegroups.com
Subject: [Rails] Re: [ANN] DrySQL

[Bryan Evans]

Matt Scilipoti wrote:
> You all can get free copies of SQl Server Express from

> http://msdn.microsoft.com/vstudio/express/.
>
> _____
>

Thanks Matt

That'll do quite nicely. Time to dust off my Windows box

- Bryan

[Sam]

Is Oracle support in the works? This seems perfect for me, but alas, no
Oracle support.

[Bryan Evans]

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

[Bryan Evans]

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.

DB2 and Oracle support will follow shortly

Cheers.

[jzakiya]

Please support Sqlite, if you don't already have plans to do so.

Thanks

Jabari

[David Mitchell]

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...

Regards

Dave M.

[Ike]

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.

[Jeremy Evans]

On 11/17/06, Ike <rvin...@hotmail.com> wrote:
> Can I use it with scaffolding_extension ?

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.

Jeremy

[Bryan Evans]

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.

Cheers.

[Bryan Evans]

Sam wrote:
> Is Oracle support in the works? This seems perfect for me, but alas, no
> Oracle support.

Sam (and any other Oracle users out there that might be following this
thread):

DrySQL now supports Oracle, as of version 0.1.4

Cheers.

http://drysql.rubyforge.org

[S. Robert James]

Looks great.

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)

[Bryan Evans]

Hi Robert

Thanks for the feedback.

Do you mind posting your suggestions to the DrySQL discussion forum?
http://rubyforge.org/forum/?group_id=2438

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.

Thanks.