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

On Oct 16, 2010, at 8:45 , David Masover wrote:
>=20
>> It's quite possible that the answer on how to get Haml to interpret =
stuff
>> was staring me in the face at some point, and I missed it. I'm afraid =
that
>> doesn't change my point at all.
>=20
> Actually, it does entirely.

Only if you ascribe the wrong point in the first place.

> It changes your point from "I can't believe Ruby=20
> won't let me do this," or "I can't believe Ruby makes it so difficult =
to do=20
> this," to "I might have missed how to do this." One is a statement =
about the=20
> tool itself -- the language, the framework, or the community behind it =
-- and=20
> the other is a statement about your ability to interpret it.
>=20
> It's still a good point, but it's a much more humble one.

array_of_points_in_previous_paragraph.match(mypoint) =3D> nil

>> Whether I'm too ignorant to figure out from the source code how to
>> fricassee, or the source code's so poorly written that most people =
can't
>> figure it out, or the docs fail to explain it, or it just can't do =
that in
>> the first place, the end result is the same: no fricassee-ing.
>=20
> However, those are each very different problems with very different =
solutions.
>=20
> If it's just you, then I should do what I can to give you the tools =
you need=20
> to be able to figure it out yourself, should you need to. I've been =
trying to=20
> do that here.

And thank you, but really; please don't try and solve the problems that =
I used as examples. They are no longer blocking items, and I do not need =
to fix them.=20

I started with Haml in the first place because the documentation looked =
good. And it *is* good, but I eventually realized that I was having some =
pretty fundamental problems with the *paradigm* on which it's based. =
Because even if "it's just you," the best solution is not necessarily =
"do[ing] what I can to give you the tools you need=20
to be able to figure it out yourself, should you need to." In this case, =
I think a much better solution was to find a tool that worked the way I =
expected it to. Maybe my ultimate choice was *less* capable than the one =
I abandoned. But if its easier for me to use, then for me, the =
replacement will do more, and do it more easily, than the "better" tool =
that does not match well with my existing experience and knowledge. =
Quality of code notwithstanding. Documentation notwithstanding.=20

>> I kept finding
>> tutorials that would say "or you can edit the blahblah file to work =
with
>> an existing legacy database." However, I couldn't even *get* a =
blahblah
>> file to edit from either Rails or Ramaze,
>=20
> Well, but which file? If it was schema.rb, I don't know that it =
would've=20
> helped...
>=20
>> Sinatra (or rather, the ORM that came bundled
>> with Sinatra)
>=20
> Which is that? I wasn't aware Sinatra came bundled with an ORM. I =
wasn't aware=20
> that it made sense for there to be -- seems like you'd just use an ORM=20=

> directly, without Sinatra knowing or caring about it.

I don't remember. Nor does it matter (to me at least), since I =
eventually selected Ramaze and Sequel.=20


> Maybe, and I apologize if that's all it is. My point for getting into =
this was=20
> to find out where the gap between my experience of things truly being =
easy=20
> (even when starting out), and your experience of things being =
difficult or=20
> impossible.

An admirable goal.=20

> Unfortunately, we can't do that with all of your problems. For =
example, my=20
> kneejerk reaction when I see people ask "How do I tie this to a legacy=20=

> schema?" is "Don't do that, migrate to something sane." But that's =
obviously=20
> wrong.

Oh, good. See below.

> For what it's worth, as badly as we might need better documentation =
and=20
> tutorials for working with legacy databases, I found it even more =
frustrating=20
> in the world of Oracle ADF, where an existing, legacy Oracle database=20=

> (complete with DBA) was assumed, and there was no easy, step-by-step =
guide on=20
> getting from zero to a Hello World app.

Wheeee. {grimace}


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

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.

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.

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

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

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

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

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

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

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

Next paradigm, see next message.