Andrei Alexandrescu (See Website For Email) wrote:
> Sean Kelly wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>>
>>> I'm not even thinking of stored procedures as logic vehicles. All stored procedures I've dealt with were little more than simply stored views (SELECT statements). If I want to see customer phone numbers and their orders, I'm glad to let the database do that efficiently by doing an inner join and passing me the information in one shot, instead of having me look at the two relevant tables for the sake of object orientedness. To say nothing about data integrity, which is best taken care of at the database level.
>>
>>
>> Stored procedures have a few advantages over inline queries:
>>
>> - Speed.  Stored procedures are pre-compiled.  This can have a tremendous impact on performance for server applications.
>> - Decoupling.  If the schema changes the app doesn't typically even need recompilation, it "just works" so long as the stored procs are updated as well.
>> - Security.  Access to the tables can be restricted to admins so the only thing a user can do is run approved stored procs.
>> - Encapsulation.  This is really an extension of decoupling, but from more of an OO perspective.  Hiding data access and manipulation behind structs has the same advantages of the same thing in OO programming languages.
>>
>> By comparison, views are pre-compiled and provide security, but not the other two features.  Quite simply, all interaction with a DB in applications I design is through stored procedures.  If a particular server doesn't support them then it's a toy.
> 
> 
> One can tell you work in finance. :o)
> 
> Then probably a framework that does what RoR does, plus offers tighter binding to large-scale databases (in addition to better speed and checking), could fill a niche that today RoR does not address for a mix of practical and philosophical reasons?
> 
> 
> Andrei

That's just one of the reasons we're doing it

Andrei Alexandrescu (See Website For Email) wrote:
> Sean Kelly wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>>
>>> I'm not even thinking of stored procedures as logic vehicles. All stored procedures I've dealt with were little more than simply stored views (SELECT statements). If I want to see customer phone numbers and their orders, I'm glad to let the database do that efficiently by doing an inner join and passing me the information in one shot, instead of having me look at the two relevant tables for the sake of object orientedness. To say nothing about data integrity, which is best taken care of at the database level.
>>
>> Stored procedures have a few advantages over inline queries:
>>
>> - Speed.  Stored procedures are pre-compiled.  This can have a tremendous impact on performance for server applications.
>> - Decoupling.  If the schema changes the app doesn't typically even need recompilation, it "just works" so long as the stored procs are updated as well.
>> - Security.  Access to the tables can be restricted to admins so the only thing a user can do is run approved stored procs.
>> - Encapsulation.  This is really an extension of decoupling, but from more of an OO perspective.  Hiding data access and manipulation behind structs has the same advantages of the same thing in OO programming languages.
>>
>> By comparison, views are pre-compiled and provide security, but not the other two features.  Quite simply, all interaction with a DB in applications I design is through stored procedures.  If a particular server doesn't support them then it's a toy.
> 
> One can tell you work in finance. :o)

:-)

> Then probably a framework that does what RoR does, plus offers tighter binding to large-scale databases (in addition to better speed and checking), could fill a niche that today RoR does not address for a mix of practical and philosophical reasons?

Probably.  I'll admit to not being too terribly familiar with RoR, but it's an appealing concept.  I'll really have to read up on it so I can contribute more to the discussion.

For what it's worth, one of my first jobs was writing systems to do customized telephony processing for a switched long-distance carrier. Much of the actual logic, in addition to the call records, user data, etc, was stored in SQL.  It was a closed system so security wasn't much of an issue, but the necessary performance would have been impossible to achieve without stored procedures.  So I'll admit to being slightly baffled at why many web servers and other popular technologies nowadays don't seem to consider them important (MySQL didn't have them until recently AFAIK).  Is it simply that automated code generation is more valuable from a cost perspective?


Sean

kris wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Sean Kelly wrote:
>>
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>
>>>>
>>>> I'm not even thinking of stored procedures as logic vehicles. All stored procedures I've dealt with were little more than simply stored views (SELECT statements). If I want to see customer phone numbers and their orders, I'm glad to let the database do that efficiently by doing an inner join and passing me the information in one shot, instead of having me look at the two relevant tables for the sake of object orientedness. To say nothing about data integrity, which is best taken care of at the database level.
>>>
>>>
>>> Stored procedures have a few advantages over inline queries:
>>>
>>> - Speed.  Stored procedures are pre-compiled.  This can have a tremendous impact on performance for server applications.
>>> - Decoupling.  If the schema changes the app doesn't typically even need recompilation, it "just works" so long as the stored procs are updated as well.
>>> - Security.  Access to the tables can be restricted to admins so the only thing a user can do is run approved stored procs.
>>> - Encapsulation.  This is really an extension of decoupling, but from more of an OO perspective.  Hiding data access and manipulation behind structs has the same advantages of the same thing in OO programming languages.
>>>
>>> By comparison, views are pre-compiled and provide security, but not the other two features.  Quite simply, all interaction with a DB in applications I design is through stored procedures.  If a particular server doesn't support them then it's a toy.
>>
>>
>> One can tell you work in finance. :o)
>>
>> Then probably a framework that does what RoR does, plus offers tighter binding to large-scale databases (in addition to better speed and checking), could fill a niche that today RoR does not address for a mix of practical and philosophical reasons?
>>
>>
>> Andrei
> 
> That's just one of the reasons we're doing it

Ok, I even bought a book on RoR about 6 months back but unfortunately have not had the time to read but a few chapters so far, and have evidently forgotten most of that.

In the .NET world, database application 'code generators'(*) have become all the rage recently as well, and I recognize that some of what has been discussed recently has been done with/in those. I think a big reason for their popularity in that domain has been the demand to move apps. from ASP to .NET (for applications where the database designs have been well established).

So... First, I've got to ask:

- What application domain is RoR really supposed to be superior for?
- Has it proved itself to be superior in 'real-world' large-scale development of new software (against new as opposed to well established databases)?
- Are RoR code generation facilities often left behind as the app. dev. process proceeds from prototype to final product?
- How does RoR differ from the aforementioned Code Generators?
- Are there any well defined studies suggesting that RoR developed apps. are cheaper than, say, apps. developed with PHP, using a traditional development approach?
- Is RoR here to stay?

Then I've got to ask: How could D possibly improve on RoR enough to get people to move away from RoR to DeRailed?

In the context of language design, Ruby may have garnered a reputation from RoR, but by the time a comparable D lib. is developed, how likely is it that RoR will still be a "hot" technology?

(*) The code generators I'm speaking of generate the read/write stored procs. from DB metadata (the 'catalog' or INFORMATION_SCHEMA), and then generate the .NET wrapper classes/containers for those. Some of them go so far as to incorporate change control tools to compare the current version with a new version generated after a schema change, etc. to protect against over-writing customized DB code, which in itself defeats the purpose of automatic code generation.

In my current little enclave of the IT world, code generators would most often not be worth the trouble, because DB metadata changes quite a lot from prototype to finished product, and quite a bit of business logic is best done within application specific stored procs, functions, constraints, etc. Heck it's hard to even keep Erwin up to date with the pace with which some of this metadata changes.

As a classic example, code generators will generate code based on a primary key or perhaps indexes; perhaps a select by proc for each column in the PK and/or Indexes, and one for the whole table. If you want to select a range, i.e.: Males in a certain ZIP CODE from the EMPLOYEES table w/o developing a custom stored proc., using inline SQL or adding GENDER and ZIP CODE to the primary key or separate/composite indexes (which would often be madness with low cardinality data like that), you'd have to haul all of the data from that table into a .NET collection and filter from there, instead of doing it where it makes the most sense: in a SQL statement WHERE clause. Now consider all of the different queries any large scale application would likely do and it becomes apparent why code generation can actually be a hindrance to application development in this context.

Thanks,

- Dave

Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Sean Kelly wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>
>>>> I'm not even thinking of stored procedures as logic vehicles. All stored procedures I've dealt with were little more than simply stored views (SELECT statements). If I want to see customer phone numbers and their orders, I'm glad to let the database do that efficiently by doing an inner join and passing me the information in one shot, instead of having me look at the two relevant tables for the sake of object orientedness. To say nothing about data integrity, which is best taken care of at the database level.
>>>
>>> Stored procedures have a few advantages over inline queries:
>>>
>>> - Speed.  Stored procedures are pre-compiled.  This can have a tremendous impact on performance for server applications.
>>> - Decoupling.  If the schema changes the app doesn't typically even need recompilation, it "just works" so long as the stored procs are updated as well.
>>> - Security.  Access to the tables can be restricted to admins so the only thing a user can do is run approved stored procs.
>>> - Encapsulation.  This is really an extension of decoupling, but from more of an OO perspective.  Hiding data access and manipulation behind structs has the same advantages of the same thing in OO programming languages.
>>>
>>> By comparison, views are pre-compiled and provide security, but not the other two features.  Quite simply, all interaction with a DB in applications I design is through stored procedures.  If a particular server doesn't support them then it's a toy.
>>
>> One can tell you work in finance. :o)
> 
> :-)
> 
>> Then probably a framework that does what RoR does, plus offers tighter binding to large-scale databases (in addition to better speed and checking), could fill a niche that today RoR does not address for a mix of practical and philosophical reasons?
> 
> Probably.  I'll admit to not being too terribly familiar with RoR, but it's an appealing concept.  I'll really have to read up on it so I can contribute more to the discussion.
> 
> For what it's worth, one of my first jobs was writing systems to do customized telephony processing for a switched long-distance carrier. Much of the actual logic, in addition to the call records, user data, etc, was stored in SQL.  It was a closed system so security wasn't much of an issue, but the necessary performance would have been impossible to achieve without stored procedures.  So I'll admit to being slightly baffled at why many web servers and other popular technologies nowadays don't seem to consider them important (MySQL didn't have them until recently AFAIK).  Is it simply that automated code generation is more valuable from a cost perspective?
> 

Great question - I've always considered stored procs. an absolute must for performance, user level security, etc... Consider also that many web client apps. won't pass a code security audit now-a-days if they contain inline SQL anywhere outside of the DB (because of the SQL injection threat), although maybe RoR encapsulates things in such a way as to protect against that as well.

> 
> Sean

comments inline
Andrei Alexandrescu (See Website For Email) wrote:
> Robby wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> After yesterday's hubbub, Judge Judy called and punished me to read about RoR, in addition to the obligatory sentence of helping a little old lady cross the street five times a week.
>>>
>>> So I went and read the nice tutorial at:
>>>
>>> http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html 
snipped
>>
>> 1 & 2 depend on a couple of things in relation to RoR.
>>
>> Since classes absorb the schema of the table they represent, if a data type of a column changes, it can handle it in the means of generic find, save, etc. However, if there is logic in the code that depends on that type, it's obviously going to fail.
> 
> Makes sense. So if all Ruby does is e.g. display a column, which I assume is a generic operation with uniform syntax over all types, the type of that column could be anything. If, on the other hand, Ruby does some math against a column, and that column changes from number to string, runtime errors would ensue.
> 
Exactly, access is transparent as long as you don't use it as the previous type.

> What if there is a web page that accepts that column? Say the old type was a string (so the appropriate form field is a textbox), and the new type is a date (so the appropriate form field is three drop-down boxes). Is Ruby's HTML generator going to figure things out and spit the appropriate HTML page?
> 

It actually uses a form of template language, so any logic that depends on a certain type in the view would also need to adapt to the new logic.

>> Again with the addition of a column, it's absorbed by the class (meaning that there is a property generated at runtime for access to the class implementation.
> 
> Alright. And are there any operations (e.g. "print all columns") that will naturally encompass the new column too?
> 
Yeah, you can get a hash of all columns, and you can access it via its property as aforementioned.

>> If a table is added RoR doesn't care about it, but you can't use it in an association, due to the fact that the machinery needed for represented associations needs to be generated against that new table.
> 
> Interesting. So here's a limitation that might be addressed. Do all of today's database engines (e.g. mysql) offer structure inspection (e.g. "enumerate tables in this database", "enumerate fields in this table"...)?
> 
Though there may be some slight differences between what you *can* get,  I'm fairly sure that most/all databases have a metadata implementation.

>> So how does it handle changes? Pretty blindly, as long as your changes don't change any logic you've predetermined into some code. including associations (like belongs_to (where you've changed the name of the foreign key)
>>
>> Bonus Question:
>> Rails is pretty ignorant of the relationships defined in the database itself DHH (author of RoR) has his reasonings listed here
>> http://www.loudthinking.com/arc/000516.html
> 
> Interesting. I happen to disagree with the author, and the "you'll have to pry that logic from my dead, cold object-oriented hands" part definitely sets off a blinking red LED somewhere, but I'm not a DB expert nor a Ruby expert so possibly I'm even misunderstanding things.
> 
I think they're taking a simplicity route when it comes to this (I can't read minds, but I'm assuming so) and there's some things I don't like about it either ~ namely you need to be explicit about validating a variable that the database provides you information for.

Example:
varchar with a length limitation of 255 characters and a default of "none". The length limitation and the default needs to be represented in the model class that represents the table, even though it's obvious that that validation should be generated as well (I mean, hello?).

Also of note would be using foreign keys to determine relationships. Of course this would need to be done in an delicate manner (that link has some pretty good ideas via foreign keys and determining relationships. RoR could take care of this information for you, but you have to explicitly state what you want to do (pros and cons of course)

> I'm not even thinking of stored procedures as logic vehicles. All stored procedures I've dealt with were little more than simply stored views (SELECT statements). If I want to see customer phone numbers and their orders, I'm glad to let the database do that efficiently by doing an inner join and passing me the information in one shot, instead of having me look at the two relevant tables for the sake of object orientedness. To say nothing about data integrity, which is best taken care of at the database level.
> 
> The whole idea of manipulating data at table level and compulsively delaying absolutely all meaning to the application level reminds me of dBase and the 1980s.
Keep in mind that you can eager load other tables as you go through find methods, this allows you to either pull from the single table, or pull all related tables (while RoR writes an innner join behind the scenes)

> 
> Anyhow, what I think might be good for most people is to write a SELECT statement that does something, and have the columns of that SELECT automatically available for further processing. I understand RoR doesn't do that.
> 
(not directly (that I recall), however you can define your own where clauses through the find methods generated on each model class.

There's some cool Ruby features that come into play during finders consider the following.
User.find_all_by_street_and_city(street, cities)
Ruby being dynamically typed has a method_missing function to all objects, if it's overrided any function calls that don't exist are routed though it, if it isn't an error is thrown.

The example above generates the where clause behind the scenes using that approach, lil tidbit :)
>> I have read about hacks to get procs to work under oracle, though I really haven't invested any time to the situation, as I've never used the db (firebird mainly)
>>
>> (Not Defending his choices, nor am I an authoritative voice on RoR, besides the couple of patches back to it, I'm just a user - though limited as of late).
>>
>> If these answers don't answer what you're looking for feel free to let me know
> 
> Thanks, the answers were exactly to the point. By and large, I'm interested in seeing strengths and limitations in the RoR approach, and making an impression whether a more static approach would make a big difference (better DB <-> code binding, better error detection, faster execution).
> 
> After all, the approach wouldn't even feel much more static: with rdmd, fast compilation, and the bang syntax, D can pretty much have the feel of an interpreter.
> 
> 
> Andrei

And consider that Ruby *needs* to shovel a lot of work elsewhere for performance reasons first and foremost while D could, by design implement the whole stack. And honestly I can't think of any of the alternative frameworks that can truly say the same.

Some things about RoR make it interesting to work with, smart includes based on context (templates), smart template calling via the controllers actions, built in routing (kind of like url rewriting with the m,v,c's all considered. and conventions on column naming
created_on inserting a time when the model is first saved,
updated_on inserting a time when the object is resaved
built in support for nested tree models, lists, etc.

There's a lot of things they've gotten right, and while its obvious that performance wasn't the first thought, the idea of addressing performance as the concerns come in while having something implemented already is commendable (I've watched, and been a part of several things that are so performance inclined, it's never considered.. 1.0 ready).

> So... First, I've got to ask:
> 
> - What application domain is RoR really supposed to be superior for?
> - Has it proved itself to be superior in 'real-world' large-scale development of new software (against new as opposed to well established databases)?
Both of these questions come across as "is this thing enterprise" (plus whatever press release idiom). All I can say is glance over the RoR site and look at the sites running it, there's some small, some big, a lot of  in the middle.
> - Are RoR code generation facilities often left behind as the app. dev. process proceeds from prototype to final product?
There's a concept in RoR called scaffolding, where the views are generated at runtime, but this is for rapid prototyping. But it depends on what you're talking about, the runtime active record generation is there through the entire cycle, and obviously the rest you're going to change as you develop
> - How does RoR differ from the aforementioned Code Generators?
because it's the whole package, it's not just a database layer.
> - Are there any well defined studies suggesting that RoR developed apps. are cheaper than, say, apps. developed with PHP, using a traditional development approach?
More enterprise speak?
> - Is RoR here to stay?
I'd say the adoption and the momentum is going to keep it in swing for quite a while, how long? no clue.. I mean, back in the day Struts was the thing (bleh), and it's slowly becoming defunct. Can you be productive in RoR, sure, can you improve it? Sure, it's all about tastes.. but if you want something in the terms of an independent report on how great it is, I can't help. I've used it, it's worked for me on a quite large intranet application, but nothing is the be all end all.

> 
> Then I've got to ask: How could D possibly improve on RoR enough to get people to move away from RoR to DeRailed?
> 
It shouldn't be able moving people from, to d's implementation, it's about providing a strong stack of development tools to allow people who want to code in d on the client, on the server and indirectly, for the web.
> In the context of language design, Ruby may have garnered a reputation from RoR, but by the time a comparable D lib. is developed, how likely is it that RoR will still be a "hot" technology?
> 
I'd stay it will grow as long as its members continue to take the complexity out of a development stack for the web and simplify it.
> (*) The code generators I'm speaking of generate the read/write stored procs. from DB metadata (the 'catalog' or INFORMATION_SCHEMA), and then generate the .NET wrapper classes/containers for those. Some of them go so far as to incorporate change control tools to compare the current version with a new version generated after a schema change, etc. to protect against over-writing customized DB code, which in itself defeats the purpose of automatic code generation.
> 
> In my current little enclave of the IT world, code generators would most often not be worth the trouble, because DB metadata changes quite a lot from prototype to finished product, and quite a bit of business logic is best done within application specific stored procs, functions, constraints, etc. Heck it's hard to even keep Erwin up to date with the pace with which some of this metadata changes.
> 
There are tools out there for deployment, and RoR has some ability to adapt to schema changes, it's not flawless, but it's avail.
> As a classic example, code generators will generate code based on a primary key or perhaps indexes; perhaps a select by proc for each column in the PK and/or Indexes, and one for the whole table. If you want to select a range, i.e.: Males in a certain ZIP CODE from the EMPLOYEES table w/o developing a custom stored proc., using inline SQL or adding GENDER and ZIP CODE to the primary key or separate/composite indexes (which would often be madness with low cardinality data like that), you'd have to haul all of the data from that table into a .NET collection and filter from there, instead of doing it where it makes the most sense: in a SQL statement WHERE clause. Now consider all of the different queries any large scale application would likely do and it becomes apparent why code generation can actually be a hindrance to application development in this context.
> 
> Thanks,
> 
> - Dave

Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Sean Kelly wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>
>>>> I'm not even thinking of stored procedures as logic vehicles. All stored procedures I've dealt with were little more than simply stored views (SELECT statements). If I want to see customer phone numbers and their orders, I'm glad to let the database do that efficiently by doing an inner join and passing me the information in one shot, instead of having me look at the two relevant tables for the sake of object orientedness. To say nothing about data integrity, which is best taken care of at the database level.
>>>
>>> Stored procedures have a few advantages over inline queries:
>>>
>>> - Speed.  Stored procedures are pre-compiled.  This can have a tremendous impact on performance for server applications.
>>> - Decoupling.  If the schema changes the app doesn't typically even need recompilation, it "just works" so long as the stored procs are updated as well.
>>> - Security.  Access to the tables can be restricted to admins so the only thing a user can do is run approved stored procs.
>>> - Encapsulation.  This is really an extension of decoupling, but from more of an OO perspective.  Hiding data access and manipulation behind structs has the same advantages of the same thing in OO programming languages.
>>>
>>> By comparison, views are pre-compiled and provide security, but not the other two features.  Quite simply, all interaction with a DB in applications I design is through stored procedures.  If a particular server doesn't support them then it's a toy.
>>
>> One can tell you work in finance. :o)
> 
> :-)
> 
>> Then probably a framework that does what RoR does, plus offers tighter binding to large-scale databases (in addition to better speed and checking), could fill a niche that today RoR does not address for a mix of practical and philosophical reasons?
> 
> Probably.  I'll admit to not being too terribly familiar with RoR, but it's an appealing concept.  I'll really have to read up on it so I can contribute more to the discussion.
> 
> For what it's worth, one of my first jobs was writing systems to do customized telephony processing for a switched long-distance carrier. Much of the actual logic, in addition to the call records, user data, etc, was stored in SQL.  It was a closed system so security wasn't much of an issue, but the necessary performance would have been impossible to achieve without stored procedures.  So I'll admit to being slightly baffled at why many web servers and other popular technologies nowadays don't seem to consider them important (MySQL didn't have them until recently AFAIK).  Is it simply that automated code generation is more valuable from a cost perspective?
> 
> 
> Sean

To play devils advocate for a bit:

There are several scenarios where writing procs would seem kinda over the top, I mean, mysql handles itself quite well in performance benchmarks (not saying it's the best) while going for years not implementing them, you can even go as far to say that while they're enabled they're not there by default (MyISAM is the default and doesn't have procs?) and considering how many 'big' sites have mysql implemented  at some level it would be fair to say that procs is not the only way to go.

Note, I'm not saying not to learn how to write procs, or that they are a bad thing. The DBA in me says you need to learn them to have performance intensive apps work 'right', but someone else could say that you should learn Latin, because you'll speak and write better by doing so. However,  obviously both cases aren't exactly true in all occasions.

So there's causes and cases for both concerns, RoR seems to only work with the 'no procs, I'll control my domain logic', there may be other implementations that sees procs and views as something that is first class I'm not sure. D from a performance and expressive standpoint could implement both. It's possible and should be considered.


Another post mentions something about injects and if RoR handles it, it does. There are conventions built in to sanitize arguments going in to prevent such things.

I'm not trying to be the definitive voice on RoR, or any subject matter, just trying to give all sides to the concept. Back to Omaha HiLo, I found me a call station ;)

Robby wrote:
>> - Are there any well defined studies suggesting that RoR developed apps. are cheaper than, say, apps. developed with PHP, using a traditional development approach?
> More enterprise speak?

Guilty as charged <g> Unfortunately, no matter how promising and cool a technology is many managers have to have a solid justification to try something like RoR even for a smallish project. Heck - I don't blame the managers - I'd have to have some solid justification to divert some of my personal time over to learning RoR, because there's so much to keep up with, and much of it ends up being nothing but a temporary phenom (you mentioned Struts for example).

>> - Is RoR here to stay?
> I'd say the adoption and the momentum is going to keep it in swing for quite a while, how long? no clue.. I mean, back in the day Struts was the thing (bleh), and it's slowly becoming defunct. Can you be productive in RoR, sure, can you improve it? Sure, it's all about tastes.. but if you want something in the terms of an independent report on how great it is, I can't help. I've used it, it's worked for me on a quite large intranet application, but nothing is the be all end all.
> 
>>
>> Then I've got to ask: How could D possibly improve on RoR enough to get people to move away from RoR to DeRailed?
>>
> It shouldn't be able moving people from, to d's implementation, it's about providing a strong stack of development tools to allow people who want to code in d on the client, on the server and indirectly, for the web.

You're right - but is DeRailed really what many of the talented [tango] lib. developers should be working on (if they were so inclined to take direction)?

Andrei Alexandrescu (See Website For Email) wrote:
> After yesterday's hubbub, Judge Judy called and punished me to read about RoR, in addition to the obligatory sentence of helping a little old lady cross the street five times a week.
> 
> So I went and read the nice tutorial at:
> 
> http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html 
> 
> 
> I have a couple of questions that I assume will be easy to answer by anyone who actually has used RoR.
> 
> On the second page of the tutorial, the authors describe how they write SQL code to create tables, and then how they invoke Ruby to parse that SQL code and generate (I assume) Ruby wrappers for it.
> 
> Now consider that the database changes: new tables, new fields, different types for existing fields, etc.
> 
> 1. Is now the generated Ruby code is out of sync with the database?
> 
> 2. In case it is out of sync, what is the way to bring it back in sync? Manual editing of the Ruby code? Editing the SQL and then regenerating the wrappers? Some automated way?
> 
> An additional question: most interesting work in databases is done through views (SELECT statements) and stored procedures. Can Ruby parse such stuff and generate appropriate wrappers? If so, what happens when the views and stored procedures change?
> 
> I'm asking these questions because I want to figure whether automating the task of keeping in sync with a database, plus the additional type safety and speed, are significant advantages in the Web/DB domain. In such a scenario, error messages like the one in Part 2 (http://www.onlamp.com/pub/a/onlamp/2007/01/05/revisiting-ruby-on-rails-revisited-2.html?page=4) may be avoided; the code simply fails to compile. I know of domains where such advantages are very important, but I'm not sure how the Web/DB domain feels about it.
> 
> 
> Andrei

Hum, in the context of the previous discussion of 1.005 features, I too have been trying to understand what makes Rails so special. After reading that article, it is my understanding that most of the goodness of Rails comes from the ability to generate Ruby code from the database's SQL schema, where that Ruby code handles all or most of the ORM logic. Is that correct? If so, is there anything special about Ruby about the language of Rails? Couldn't a similar framework be made for other languages, like Java for example, with similar results as Rails?

Also, from the article, I've identified two DSLs: SQL and rhtml (the equivalent of Java's JSPs). In both cases, Ruby code is generated from code in these two DSLs, but that code generation is performed not by the Ruby compiler during compile-time, but by an external tool (similar to parser generators for example). If so, that would be mean that the D 1.005 features are not necessarily required or useful for the "enabling of such applications", which I think was the point kris was making in the Derailed DSL thread ago. Good interoping with DSLs is decisive, but that doesn't mean the interoping needs to be done at compile-time, by the compiler.
Is this correct?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Hi Andrei,

Andrei Alexandrescu (See Website For Email) schrieb:

> Sorry, I'm not sure I understand. My understanding of the mechanism is the following:
> 
> 1. The app runs a SQL-to-target-language parser to build an idea about the database.
> 
> 2. The database folk changes the database in any number of ways. This is not a process that automatically notifies the target language application.
> 
> 3. The target language application must undergo some change to accommodate the change in the database.
> 
> I did DB/financial work in 1998. This scenario was a total bitch because we didn't have small and fast test cases for all logic code to run when the database changed. Basically it was the customer (financial analysts) who let us know when something bombed, and they actually got so used to it that they even weren't pissed anymore.
> Andrei

I understand and I know about the problem. Due to the fact that this is a serious task, which should not be answered (like before) within a simple statement, and the fact that I am not used to think and argue in english, requires that I have to write down my thoughts in german first and to translate them later. This may take a while, I hope you understand.

Allow me a few WHYs
WHY a datastore called database has such an influence/impact  on consumer applications, f.i. your Software ? I mean a database should be
a Black Box ONLY accessable through your application by using a public key in the sense of (PGP)... Your Application should master the database and not vice versa.

Since about 24 years I am in the database business and I have seen only one implemantation which keeps you away from this kind of trouble, let me quote /
Suneido has an integrated client-server relational database. The database is accessed via a language which includes administration requests and update operations as well as actual queries. The query language is based on the relational algebra language in An Introduction to Database Systems by C.J.Date.
/

D is young and refreshing: So WHY not implementing this kind of DB System in D ?

Since I know that you are very busy I hesitate to offer you a this link  but I think you will find some very interesting information worth spending a few minutes...
http://www.suneido.com/index.php?option=com_content&task=view&id=49&Itemid=1

Further. a big step
I could imagine that it could be a matter of interest to port the new MINIX  kernel into D having a DB system instead of "journaling file system"  (Beside, still wonder why this kind of filesys. is not allready reality) Why not doing  that in D ? This is indeed a  vision and as our old german chanceler "Helmut Schmidt" says : People having visions should see a doctor really quick.

Bjoern
I am convinced that having a builtin database support (however implemented) within a new language is simply needed, or can you imagine only a single simple application which does not deal with data  ?

OkeeDokee, I have to answere to your concrete question