www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - RoR, Judge Judy, and little old ladies

reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
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-revi
ited-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
Feb 10 2007
next sibling parent reply Robby <robby.lansaw gmail.com> writes:
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-
ails-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-revi
ited-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

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. 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. 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. 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 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 Cheers, Robby
Feb 11 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
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-
ails-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-revi
ited-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

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. 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?
 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?
 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"...)?
 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'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. 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.
 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
Feb 11 2007
next sibling parent reply James Dennett <jdennett acm.org> writes:
Andrei Alexandrescu (See Website For Email) wrote:

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

In my experience, yes (MySQL does, SQLite does, and all of the more traditional RDBMS's do, including PostgreSQL, Oracle, DB2, MS SQL Server, and many more). This level of "reflection" is standard. In older versions of MySQL it was accessible only via special APIs, but normally it is available via system tables/views with names something like SYS_ALL_TABLES, SYS_ALL_COLUMNS, etc., which have columns for name, type, etc, so that SQL is the interface to this metadata. -- James
Feb 11 2007
parent Brad Anderson <brad dsource.org> writes:
James Dennett wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 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"...)?

In my experience, yes (MySQL does, SQLite does, and all of the more traditional RDBMS's do, including PostgreSQL, Oracle, DB2, MS SQL Server, and many more). This level of "reflection" is standard. In older versions of MySQL it was accessible only via special APIs, but normally it is available via system tables/views with names something like SYS_ALL_TABLES, SYS_ALL_COLUMNS, etc., which have columns for name, type, etc, so that SQL is the interface to this metadata. -- James

I am currently attempting to add this metadata to Result objects in DDBI. Nothing in SVN yet, but I am making progress. I'm also working on improving the types that DDBI returns, expanding past just char[]. http://www.dsource.org/projects/ddbi BA
Feb 11 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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. Sean
Feb 11 2007
next sibling parent kris <foo bar.com> writes:
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. Sean

Amem :)
Feb 11 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
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
Feb 11 2007
next sibling parent reply kris <foo bar.com> writes:
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
Feb 11 2007
parent reply Dave <Dave_member pathlink.com> writes:
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
Feb 11 2007
parent reply Robby <robby.lansaw gmail.com> writes:
 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)?

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?

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?

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

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?
 

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?
 

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.
 

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

Feb 11 2007
parent reply Dave <Dave_member pathlink.com> writes:
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?


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?

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?

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)?
Feb 12 2007
parent reply Robby <robby.lansaw gmail.com> writes:
Dave wrote:
 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?


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

didn't want to answer those questions if they were in that context. And I agree about a lot to keep up with, which actually falls somewhat inline with the current discussion, if you've taken D as a language of choice wouldn't you want to be able to work on the web stack with D itself? The thing is the web is *so* complicated that there is always going to be generational fads and improvements.
 - Is RoR here to stay?

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?

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)?

I can't and won't speak for the Tango developers (I'm not one atm). However, one can assume that you can approach Tango as a toolkit, and considering that Mango's developers are also apart of Tango, so a toolkit for the web kinda makes sense. Also, in my opinion the best part about trying to compete with technologies in problem domains allows you to open your eyes about some improvements that may help D as a whole. Consider some of the things that Ruby does to make it so easy, reflective abilities, dynamic generation and runtime type information. Now obviously D isn't going to turn into a dynamic language, but exposing such traits that D could help a static typed langauge approach could help us all in the end. - such as runtime type information.
Feb 12 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Robby wrote:
 Also, in my opinion the best part about trying to compete with 
 technologies in problem domains allows you to open your eyes about some 
 improvements that may help D as a whole. Consider some of the things 
 that Ruby does to make it so easy, reflective abilities, dynamic 
 generation and runtime type information.
 
 Now obviously D isn't going to turn into a dynamic language, but 
 exposing such traits that D could help a static typed langauge approach 
 could help us all in the end. - such as runtime type information.

Definitely. RTTI and reflection are good to have will probably make it in D (as I mentioned, as a couple of the many applications of static introspection). The runtime code generation issue is much more problematic, so a alternative approach is to do compile-time generation for select modules. Running the compiler to generate code will be not much slower than running the interpreter of a competing language. The advantage is that the resulting code will be easier to make correct and faster. Let me put it this way. If all you need to do is recompile a couple of modules when the database schema changes (a process that is easy to automate), then this might be more attractive than a scheme that does a lot of busywork at runtime to adapt itself dynamically to a structure that seldom changes, and to fail "late" when inconsistencies in the code are revealed. Andrei
Feb 12 2007
parent Robby <robby.lansaw gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Robby wrote:
 Also, in my opinion the best part about trying to compete with 
 technologies in problem domains allows you to open your eyes about 
 some improvements that may help D as a whole. Consider some of the 
 things that Ruby does to make it so easy, reflective abilities, 
 dynamic generation and runtime type information.

 Now obviously D isn't going to turn into a dynamic language, but 
 exposing such traits that D could help a static typed langauge 
 approach could help us all in the end. - such as runtime type 
 information.

Definitely. RTTI and reflection are good to have will probably make it in D (as I mentioned, as a couple of the many applications of static introspection). The runtime code generation issue is much more problematic, so a alternative approach is to do compile-time generation for select modules. Running the compiler to generate code will be not much slower than running the interpreter of a competing language. The advantage is that the resulting code will be easier to make correct and faster. Let me put it this way. If all you need to do is recompile a couple of modules when the database schema changes (a process that is easy to automate), then this might be more attractive than a scheme that does a lot of busywork at runtime to adapt itself dynamically to a structure that seldom changes, and to fail "late" when inconsistencies in the code are revealed. Andrei

I mentioned something similar in the DeRailed thread and posted a very very rough draft[1] how something could work with D's implementation now. And now that I think about it further, that very setup could even use the new mixin/import features. What I'm currently working on is using derelict's loader setup and porting sqlite to use it, this way I'm not confined to where the sqlite.dll is on windows (ugh), then I'm going to start working on DeActive using sqlite as a test bed. I'm actually not looking at this whole thing from a RubyOnRails perspective, but for now, from a ActiveRecord perspective. I want a nice ORM setup for a gui app I'm working on, and in turn an ORM to keep track of my poker hands + backtesting for my poker bot. I just happen to have extensive experience through my old job on RubyOnRails and its implemention. [1]http://www.dsource.org/projects/tango/wiki/DeActive
Feb 12 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Feb 11 2007
next sibling parent Dave <Dave_member pathlink.com> writes:
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

Feb 11 2007
prev sibling next sibling parent reply Robby <robby.lansaw gmail.com> writes:
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 ;)
Feb 11 2007
parent reply Sean Kelly <sean f4.ca> writes:
Robby wrote:
 
 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.

Fair enough. I'll admit that the performance demands of many websites simply aren't at the level I'm accustomed to, but I'd think the impact on maintenance would still be a factor. However, I guess this is where middleware and code generation come in.
 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.

Good to know that RoR does indeed generate inline SQL as I suspected.
 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.

Yup. And I'll admit that dynamically generated queries can be very useful for some situations. I suppose I just haven't been involved in developing products where this was the most appropriate way to go. Sean
Feb 12 2007
parent Robby <robby.lansaw gmail.com> writes:
Sean Kelly wrote:
 Robby wrote:
 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.

Fair enough. I'll admit that the performance demands of many websites simply aren't at the level I'm accustomed to, but I'd think the impact on maintenance would still be a factor. However, I guess this is where middleware and code generation come in.
 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.

Good to know that RoR does indeed generate inline SQL as I suspected.
 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.

Yup. And I'll admit that dynamically generated queries can be very useful for some situations. I suppose I just haven't been involved in developing products where this was the most appropriate way to go. Sean

with a DBA, and playing DBA myself. So I fully understand where you're coming from, just trying to give a point of view from the dark side ;o).
Feb 12 2007
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
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

In my experience, there are several reasons why databases aren't ever used to their fullest potential in web applications: 1) DBA Hegemony in the workplace - devs aren't always given the rights or permissions to create stored procedures and views, even in a development environment. YMMV. The common attitude in this scenario is: "I'm Oracle 9i certified, you're not, it's my machine so it's my rules, and I golf regularly with the VP." Just imagine trying to write an application with the BOFH in the way - you're going to draft a schema in Er-Win, test it 100 ways from Sunday, hand it to him once, and pray to Bob you can code around any mistakes. Office politics and/or plain ol' bureaucracy is the key problem here. 2) Lack of experience/education. Devs don't always know much beyond basic SQL and cartesian joins. Also SQL is *weird*; things like "null != null" is hard for some folks to grasp, type conversion is hackish (or vendor-specific), and date/time wrangling is a chore so they stay where they're comfortable instead. 3) Lack of vendor conformance to features post SQL-99. Really practical things, like Limit/Top, type conversion, and so-forth are non-standard. As the SQL-99 spec ages, the major RDBMS vendors become more divergent in their application of new and useful stuff, which only hurts the educational landscape out there. The result is that more and more, developers have to stick to the lowest-common denominator which is often shored up by middleware that can inject vendor-specific features as needed. 4) Abundance of solutions to the above. With so many great middleware solutions for wrangling your database, why would you ever need to know more than basic SQL? Sure, that's like burying your head in the sand, but if it's a time-saver, you're likely going to go this route. -- - EricAnderton at yahoo
Feb 12 2007
parent Sean Kelly <sean f4.ca> writes:
Pragma wrote:
 
 In my experience, there are several reasons why databases aren't ever 
 used to their fullest potential in web applications:
 
 1) DBA Hegemony in the workplace - devs aren't always given the rights 
 or permissions to create stored procedures and views, even in a 
 development environment.  YMMV.  The common attitude in this scenario 
 is: "I'm Oracle 9i certified, you're not, it's my machine so it's my 
 rules, and I golf regularly with the VP."  Just imagine trying to write 
 an application with the BOFH in the way - you're going to draft a schema 
 in Er-Win, test it 100 ways from Sunday, hand it to him once, and pray 
 to Bob you can code around any mistakes.  Office politics and/or plain 
 ol' bureaucracy is the key problem here.

I've heard as much but haven't ever found myself in this situation. DB admins who think programmers aren't capable of writing efficient or reliable SQL so they accept work orders and implement everything themselves. The official reason seems to be that the DB admin is more aware of the performance demands of different departments, etc. I suppose this is a common case for internal applications in large firms.
 2) Lack of experience/education.  Devs don't always know much beyond 
 basic SQL and cartesian joins.  Also SQL is *weird*; things like "null 
 != null" is hard for some folks to grasp, type conversion is hackish (or 
 vendor-specific), and date/time wrangling is a chore so they stay where 
 they're comfortable instead.

This one seems to pretty common, and I suppose gives rise to #1. But then many programmers don't seem to adequately understand their language of choice, either.
 3) Lack of vendor conformance to features post SQL-99.   Really 
 practical things, like Limit/Top, type conversion, and so-forth are 
 non-standard.  As the SQL-99 spec ages, the major RDBMS vendors become 
 more divergent in their application of new and useful stuff, which only 
 hurts the educational landscape out there.  The result is that more and 
 more, developers have to stick to the lowest-common denominator which is 
 often shored up by middleware that can inject vendor-specific features 
 as needed.
 
 4) Abundance of solutions to the above.  With so many great middleware 
 solutions for wrangling your database, why would you ever need to know 
 more than basic SQL?  Sure, that's like burying your head in the sand, 
 but if it's a time-saver, you're likely going to go this route.

And here I thought there was some practical reason why things were done this way :-) But my experience as a customer for various online sites and products (MMORPGs come to mind) reinforces what you've said. I'll admit to being occasionally baffled at the problems some seem to have, but I guess it's the same everywhere. Well, good to know I haven't missed the boat, I suppose. Sean
Feb 12 2007
prev sibling parent Robby <robby.lansaw gmail.com> writes:
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-
ails-revisited.html 



 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.

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?

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

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.

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.

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.
 

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).
Feb 11 2007
prev sibling next sibling parent reply BLS <Killing_Zoe web.de> writes:
Andrei Alexandrescu (See Website For Email) schrieb:
 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-
ails-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?

In general this kind of problems are solved by implementing the observer - observeable/subject pattern.
 
 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-revi
ited-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

Bjoern
Feb 11 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
BLS wrote:
 Andrei Alexandrescu (See Website For Email) schrieb:
 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-
ails-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?

In general this kind of problems are solved by implementing the observer - observeable/subject pattern.

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
Feb 11 2007
parent reply BLS <Killing_Zoe web.de> writes:
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
Feb 12 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
BLS wrote:
 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.

I've seen Tanenbaum talking about Minix. It's a jewel; the kernel is only 4000 lines of code, and everything else is modularly implementable in user space. Writing Minix's kernel in D would definitely be an interesting D project. Andrei
Feb 12 2007
parent BLS <Killing_Zoe web.de> writes:
Hi Andrei, as promised some ideas to solve the Application is out of 
sync. with the DB

Simplified, ORM around a customer table.
Our code :

class CUSTOMER
{
	// map the table structure
	ulong id;
	char[] lastname;
	char[] firstname.

	// do something
	void write()
	void del()
	void query()
	
}

Problem -> Tablestructure is out of sync. Added Middle Initial to table 
structure.

Instead of mapping the table into concrete data types, I would kike to 
suggest to use
memory-mapped files instead;
Due to the fact that you are allways able to query the database system 
tables you should be able to
extract all nessesary information. to query, update... the db

Another solution requires that a D compiler and DDL are part ouf your 
application.
Uses
if applicationOutOfSync()
    generateAdequateCode(), compile2DDL()
LoadCodeAtRuntime()
This will at least solve the compile-time problem <g>

Bjoern



Andrei Alexandrescu (See Website For Email) schrieb:
 BLS wrote:
 
 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.

I've seen Tanenbaum talking about Minix. It's a jewel; the kernel is only 4000 lines of code, and everything else is modularly implementable in user space. Writing Minix's kernel in D would definitely be an interesting D project. Andrei

Feb 14 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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-
ails-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-revi
ited-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
Feb 12 2007
next sibling parent reply Robby <robby.lansaw gmail.com> writes:
Bruno Medeiros wrote:
snipped
 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?
 

active record (the ORM logic) coming in from other languages. Keep in mind that Rails is a MVC stack for the web, written in Ruby. The ORM is just one contribution.
 Also, from the article, I've identified two DSLs: SQL and rhtml (the 
 equivalent of Java's JSPs). 

without the cruft), rjs (javascript templating etc). SQL isn't directly used as a DSL, the metadata via database apis is used to generate code. 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).

reflective abilities. 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?
 

Feb 12 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Robby wrote:
 Bruno Medeiros wrote:
 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).

reflective abilities.

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic? -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Feb 15 2007
parent reply Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:
 Robby wrote:
 Bruno Medeiros wrote:
 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).

reflective abilities.

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

Unless you actually want to do something with that data, I assume. Sean
Feb 15 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 Bruno Medeiros wrote:
 Robby wrote:
 Bruno Medeiros wrote:
 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).

reflective abilities.

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

Unless you actually want to do something with that data, I assume. Sean

What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Feb 16 2007
parent reply Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 Robby wrote:
 Bruno Medeiros wrote:
 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).

reflective abilities.

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

Unless you actually want to do something with that data, I assume.

What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.

So say you modify your schema and the application self-adapts. Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result. This obviously cannot be generated automatically because only the programmer knows what it should be. Sean
Feb 16 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 Robby wrote:
 Bruno Medeiros wrote:
 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).

reflective abilities.

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

Unless you actually want to do something with that data, I assume.

What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.

So say you modify your schema and the application self-adapts. Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result. This obviously cannot be generated automatically because only the programmer knows what it should be. Sean

I suspect we're not understanding each other well. Of course business logic is something that only the programmer knows, and the app cannot generate that, but I'm not talking about actual business logic, just simple domain object creating, deletion, editing (and respective ORM logic). Consider this pic from the article: http://www.onlamp.com/onlamp/2006/12/14/graphics/figure011.gif where the web app allows to create a domain object (recipe). That functionality is automatically generated from the SQL tables, it is achieved without any code written (except for SQL table creation). My question was whether this functionality was generated at "pre-run" time (the scaffolding external tool), or at runtime (by the Ruby webapp and it's dynamic capabilities). -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Feb 18 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 Robby wrote:
 Bruno Medeiros wrote:
 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).

reflective abilities.

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

Unless you actually want to do something with that data, I assume.

What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.

So say you modify your schema and the application self-adapts. Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result. This obviously cannot be generated automatically because only the programmer knows what it should be. Sean

I suspect we're not understanding each other well. Of course business logic is something that only the programmer knows, and the app cannot generate that, but I'm not talking about actual business logic, just simple domain object creating, deletion, editing (and respective ORM logic). Consider this pic from the article: http://www.onlamp.com/onlamp/2006/12/14/graphics/figure011.gif where the web app allows to create a domain object (recipe). That functionality is automatically generated from the SQL tables, it is achieved without any code written (except for SQL table creation). My question was whether this functionality was generated at "pre-run" time (the scaffolding external tool), or at runtime (by the Ruby webapp and it's dynamic capabilities).

Yah, I have the same question. My current understanding is that generation is done statically (e.g. you must run the xyz program after you update your database structure...), which makes D's capability of doing that during compilation very attractive. Andrei
Feb 18 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 Robby wrote:
 Bruno Medeiros wrote:
 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).

reflective abilities.

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

Unless you actually want to do something with that data, I assume.

What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.

So say you modify your schema and the application self-adapts. Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result. This obviously cannot be generated automatically because only the programmer knows what it should be. Sean

I suspect we're not understanding each other well. Of course business logic is something that only the programmer knows, and the app cannot generate that, but I'm not talking about actual business logic, just simple domain object creating, deletion, editing (and respective ORM logic). Consider this pic from the article: http://www.onlamp.com/onlamp/2006/12/14/graphics/figure011.gif where the web app allows to create a domain object (recipe). That functionality is automatically generated from the SQL tables, it is achieved without any code written (except for SQL table creation). My question was whether this functionality was generated at "pre-run" time (the scaffolding external tool), or at runtime (by the Ruby webapp and it's dynamic capabilities).

Yah, I have the same question. My current understanding is that generation is done statically (e.g. you must run the xyz program after you update your database structure...), which makes D's capability of doing that during compilation very attractive. Andrei

I don't think it is static, based on this quote: When Active Record first uses a particular model, it goes to the database and determines the column set of the corresponding table. From there it constructs a set of Column objects. These objects are accessible using the columns( ) class method, and the Column object for a named column can be retrieved using the columns_hash( ) method. The Column objects encode the database columnís name, type, and default value. -- Agile Development with Rails, section 15.6.
Feb 20 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don Clugston wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 Sean Kelly wrote:
 Bruno Medeiros wrote:
 Robby wrote:
 Bruno Medeiros wrote:
 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).

and reflective abilities.

Hum, I had understood scaffolding to be the process where it generated Ruby code by looking at the DB schema. So if I change the DB schema, I don't have to run scaffolding again? I only need to restart the web app, since it can reflectively and dynamically create its own ORM logic?

Unless you actually want to do something with that data, I assume.

What do you mean? I am of course talking in the case where the web app works with the data, otherwise the point of needing or not needing to restart the app was moot.

So say you modify your schema and the application self-adapts. Unless it is designed to merely pass all data through to the user (which may be common in web apps), the app will require some specialized code to operate on the data to achieve the desired result. This obviously cannot be generated automatically because only the programmer knows what it should be. Sean

I suspect we're not understanding each other well. Of course business logic is something that only the programmer knows, and the app cannot generate that, but I'm not talking about actual business logic, just simple domain object creating, deletion, editing (and respective ORM logic). Consider this pic from the article: http://www.onlamp.com/onlamp/2006/12/14/graphics/figure011.gif where the web app allows to create a domain object (recipe). That functionality is automatically generated from the SQL tables, it is achieved without any code written (except for SQL table creation). My question was whether this functionality was generated at "pre-run" time (the scaffolding external tool), or at runtime (by the Ruby webapp and it's dynamic capabilities).

Yah, I have the same question. My current understanding is that generation is done statically (e.g. you must run the xyz program after you update your database structure...), which makes D's capability of doing that during compilation very attractive. Andrei

I don't think it is static, based on this quote: When Active Record first uses a particular model, it goes to the database and determines the column set of the corresponding table. From there it constructs a set of Column objects. These objects are accessible using the columns( ) class method, and the Column object for a named column can be retrieved using the columns_hash( ) method. The Column objects encode the database columnís name, type, and default value. -- Agile Development with Rails, section 15.6.

I asked a friend of mine who knows more about Ruby than me, and he said that Rails can actually do that generation in both occasions (runtime and "pre-run" time). If that's the case it surely would explain the confusion. :) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Feb 21 2007
parent Gregor Kopp <gk cutcopy.com> writes:
Bruno Medeiros schrieb:
 
 I asked a friend of mine who knows more about Ruby than me, and he said 
 that Rails can actually do that generation in both occasions (runtime 
 and "pre-run" time). If that's the case it surely would explain the 
 confusion. :)
 

I can confirm this! You have the possibilities to do it this or that way. Personally I use it this way: First, I use dynamically generated scaffolding to look, that everything is right with my models, and then, if my models are okay, then i use a builtin script to generate written files for it. After that i iterate over the files over and over again, till i'm finished with it.
Feb 22 2007
prev sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros 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-
ails-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-revi
ited-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?

That is correct. But everybody is doing the run-time schtick, so doing it during compilation would bring an edge (error detection and faster execution). Andrei
Feb 12 2007