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

On Oct 16, 2010, at 8:45 , David Masover wrote:
> 
>> 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.
> 
> 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 
> won't let me do this," or "I can't believe Ruby makes it so difficult to do 
> this," to "I might have missed how to do this." One is a statement about the 
> tool itself -- the language, the framework, or the community behind it -- and 
> the other is a statement about your ability to interpret it.
> 
> It's still a good point, but it's a much more humble one.

array_of_points_in_previous_paragraph.match(mypoint) => 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.
> 
> However, those are each very different problems with very different solutions.
> 
> If it's just you, then I should do what I can to give you the tools you need 
> to be able to figure it out yourself, should you need to. I've been trying to 
> 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. 

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

>> 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,
> 
> Well, but which file? If it was schema.rb, I don't know that it would've 
> helped...
> 
>> Sinatra (or rather, the ORM that came bundled
>> with Sinatra)
> 
> Which is that? I wasn't aware Sinatra came bundled with an ORM. I wasn't aware 
> that it made sense for there to be -- seems like you'd just use an ORM 
> 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. 


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

An admirable goal. 

> Unfortunately, we can't do that with all of your problems. For example, my 
> kneejerk reaction when I see people ask "How do I tie this to a legacy 
> schema?" is "Don't do that, migrate to something sane." But that's obviously 
> wrong.

Oh, good. See below.

> For what it's worth, as badly as we might need better documentation and 
> tutorials for working with legacy databases, I found it even more frustrating 
> in the world of Oracle ADF, where an existing, legacy Oracle database 
> (complete with DBA) was assumed, and there was no easy, step-by-step guide on 
> 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. 

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. 

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. 

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. 

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. 

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. 

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. 

Next paradigm, see next message.