Re: ODBC app in Ruby - I don't believe it.

My apologies if quoting is mangled, there's only so much I can do
about broken email clients...

On Sun, Oct 17, 2010 at 2:09 AM, Dave Howell
<[e-mail]> wrote:
> I would suggest, however, that the best place to start is to understand that there's a serious problem with the very idea of "legacy"
> databases. My database is NOT a legacy database. It's a brand new installation, it's entirely under my control. I am beholden to
> nobody. To use the term "legacy" to describe it is extremely misleading. However, I happen to feel that the database itself is the
> most well suited component to ensure the integrity of the data, and the more I work with the various Ruby-based widgets, tools, and
> libraries, the more I believe this. I will NEVER give my Ruby code or an ORM the ability to alter my DB schema. I also considered
> and rejected MySQL as the datastore, because it does not meet my minimum standards for data safety.

Legacy system:

Wikipedia:
"A legacy system is an old technology, computer system, or application
program that continues to be used, typically because it still
functions for the users' needs, even though newer technology or more
efficient methods of performing a task are now available."

ichnet.org:
"Those systems in existence and either deployed or under development
at the start of a modernization program. All legacy systems will be
affected by modernization to a greater or lesser extent. Some systems
will become transition systems before they are retired."

bbn.com:
"A customer's existing system, often a database system."

So, yes, your database is a legacy system, as far as switching horses
(to a very different programming style and methodology for web
development) mid-race is concerned.

>
> You said above that your kneejerk reaction was to "migrate to something sane." We agree that that's not really the right response,
> but we might not agree on why. I read the Rails/ActiveRecord documentation with what eventually became horror. MySQL's little
> foibles (like silent truncation of over-long strings) were nothing compared to the gaping holes and systemic inadequacies of
> ActiveRecord. I assumed at first I was just missing an entire chunk of documentation, the one where it talked about how you could
> create foreign key relationships *in the database,* among other things. Instead I found pages of documentation about 'migration,'
> where the docs *bragged* about how easy it was to just swap out MySQL for SQLite, or vice versa, because it was supporting only
> the least common denominator of functionality from the DB engines.

The least common denominator being, allegedly, the SQL standard. Which
pretty much *no existing SQL database supports in a portable fashion*.
So, what shall be done give that, a) time, b) money, c) knowledge are
in finite supply? ActiveRecord/Rails opted for portability as much as
is possible. Frankly, you can be happy that it is trivial now to
change ActiveRecord for something different and have Rails still work.

> I make my database engine work for a living. While it would, in theory, be possible to "migrate" my data from PostgreSQL to Oracle,
> SQLServer, or (I suspect) DB2, I believe it would be extremely difficult to replicate the current functionality with MySQL, and utterly
> impossible with SQLite. In practice, moving to a new DB store would require a lot of handwork, rewriting various triggers, creating new
> ones to replace the custom data types, adding new linking tables to replace the foreign key arrays, and so on. There is no way that it
> could be done by generic migration code.

And given that you know how much work you face, how much *DB engine
specific* work at that, you seriously expect a tool to cover every
possible case and usage scenario? That's a rather arrogant attitude at
best.

> I eventually found some other blogs wherein people had commented on similar experiences, which was why I wanted to reassure the
> original poster that "it wasn't just him not getting it" or some such thing. I knew when I started working on this project that I would find
> myself holding some assumptions that were going to trip me up, and I've tried to keep an open mind and learn new ways of doing stuff
> and of thinking about stuff. However, building my web apps from a data-centric, and DB-centric, perspective is not going to change, at
> least not until some kind of reason for doing so that's a few orders of magnitude more compelling than anything I've seen to date
> comes along.

Rails is a result of work done 37signals, derived from the experiences
these people had when creating brand spanking new web applications.
That's the space Rails occupies and, for better or for worse,
dominates.

Rails never was good at being put on top of existing databases or to
fit into existing systems, since that is not the development goal for
Rails.

> Templating foundered on more or less the same problem. I first had to 'template' web pages using Microsoft's IDC/HTX system. This
> would be what they had *before* they invented Active Server Pages. It was pretty awful. (For one thing, no cookies. Period.) A year or
> two later, I went looking for an alternative. I evaluated ASP, WebObjects, SilverStream, and Tango, and Tango blew my socks off. It
> did not use templating as such. Each 'page' was an interpreted file, the file contained subunits that would have markup, and then you
> could also embed code within the markup material. Not unlike Haml's partials, but it all happened within a single file.

I have the distinct feeling that you are strongly opposed to Java's
"One File, One Class" approach, too.

>
> That was in 1997. I was expecting, upon my return to DB<->web programming, to find things fabulously more advanced. I didn't
> expect to find them almost unrecognizable. Unfortunately, the lack of recognition isn't because everything's fabulously more
> advanced. There's been a lot of sideways motion.

I can't comment on that, but I doubt that expecting that programming
changed since the last paradigm shift to OOP is an approach that lends
itself to safety (alas). The changes were in methodology, like the
Model-View-Controller pattern, which nicely separates area of
responsibility of code, minimizing dependencies of otherwise unrelated
code.

> The tutorial that I kept hoping to find, and that I didn't see *anywhere*, was the one that would start out like "Let's build a blogging
> site. Here's the tables we're going to use. Here's the SQL code you would run on your database to create them. Now, run this
> magical command and Railamanatra will construct models and web pages and views and stuff to help you get started . . . ." or
> maybe "Here's how to convert your current PHP-based blogging site to Railamanatra, without having to alter the existing data or
> database."

That's because Rails aims to be all-encompassing. You write everything
you need in one language, instead of having to switch gears going from
Ruby to SQL to HTML. And nobody said that Rails fits your problem
space, either.

Rails is excellent if you can control everything in a project, from DB
schema, to server deployment, to the server's software. It's not a
good tool if you want to make a square peg fit a round hole, however.

> So, in a nutshell, there are two paradigms that are pervasive in the current Ruby-tool-for-web community that will tend to make people
> who don't share them incredibly miserable. The one I've mostly covered above is the middleware-centric perspective, and it seems
> fairly obvious to me this is because most of the current tools were created by people who started with Rails. Rails, as the designers
> clearly explain, is "opinionated software." I *like* that. I agree with their idea that there's a lot of merit in making something that does
> NOT try to be everything-agnostic, that provides suggestions, guide rails, defaults, and implicit assumptions. However, in this
> particular case, MY perspective is that the data is god-like, the DB engine is the emperor, and the middleware are its lackeys and
> peons, and Rails really hates that. Alas, all the viable alternatives I found still believe that to one degree or another. I picked Ramaze
> in the end because it felt less strongly about that than my other options.

Then don't use Rails. It's as easy as that.

> In fact, I think that this 'opinion' is actually quite mild in some of the other platforms; the authors were, in fact, trying to go for a more
> generalized approach. But the *documentation* still reflects that original Rails point of view more strongly.

That could be because the Merb and Rails teams (and code) merged
between Rails 2.0 and the current Rails 3.0 release. And as we all
know, the documentation ranks pretty low on teh "things developers do
for fun" scale (much to my own annoyance).

> Just figuring out that I had to go shopping for multiple different parts in order to replace what Tango did for me was one unexpected
> stumble. When I did, then I realized that, for me, starting with the ORM was absolutely the right thing to do. I had a seriously
> complex schema and if my ORM couldn't keep up, it was pretty irrelevant what else I had. And Sequel has outstanding, phenomenal
> documentation, and appeared to have a notably data-centric perspective. Once I had that, then I picked out things that went well with
> it.

Fortunately, thanks to the middle-ware centric approach, you can
actually exchange these things with relative ease.

Well, to cut a long story short: Don't be surprised that Rails doesn't
fit your problem. Instead of venting about it, move on, and look for
something that fits, or build your own (or fork Rails / the parts of
Rails you like, and build from that). It's open source, nobody'll stop
you.

-- 
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.