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


Both of these questions come across as "is this thing enterprise" (plus 
whatever press release idiom). All I can say is glance over the RoR site 
and look at the sites running it, there's some small, some big, a lot of 
  in the middle.

 - Are RoR code generation facilities often left behind as the app. dev. 
 process proceeds from prototype to final product?


There's a concept in RoR called scaffolding, where the views are 
generated at runtime, but this is for rapid prototyping. But it depends 
on what you're talking about, the runtime active record generation is 
there through the entire cycle, and obviously the rest you're going to 
change as you develop

 - How does RoR differ from the aforementioned Code Generators?


because it's the whole package, it's not just a database layer.

 - Are there any well defined studies suggesting that RoR developed apps. 
 are cheaper than, say, apps. developed with PHP, using a traditional 
 development approach?


More enterprise speak?

 - Is RoR here to stay?


I'd say the adoption and the momentum is going to keep it in swing for 
quite a while, how long? no clue.. I mean, back in the day Struts was 
the thing (bleh), and it's slowly becoming defunct. Can you be 
productive in RoR, sure, can you improve it? Sure, it's all about 
tastes.. but if you want something in the terms of an independent report 
on how great it is, I can't help. I've used it, it's worked for me on a 
quite large intranet application, but nothing is the be all end all.


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


It shouldn't be able moving people from, to d's implementation, it's 
about providing a strong stack of development tools to allow people who 
want to code in d on the client, on the server and indirectly, for the web.

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


I'd stay it will grow as long as its members continue to take the 
complexity out of a development stack for the web and simplify it.

 (*) The code generators I'm speaking of generate the read/write stored 
 procs. from DB metadata (the 'catalog' or INFORMATION_SCHEMA), and then 
 generate the .NET wrapper classes/containers for those. Some of them go 
 so far as to incorporate change control tools to compare the current 
 version with a new version generated after a schema change, etc. to 
 protect against over-writing customized DB code, which in itself defeats 
 the purpose of automatic code generation.
 
 In my current little enclave of the IT world, code generators would most 
 often not be worth the trouble, because DB metadata changes quite a lot 
 from prototype to finished product, and quite a bit of business logic is 
 best done within application specific stored procs, functions, 
 constraints, etc. Heck it's hard to even keep Erwin up to date with the 
 pace with which some of this metadata changes.
 


There are tools out there for deployment, and RoR has some ability to 
adapt to schema changes, it's not flawless, but it's avail.

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


 More enterprise speak?


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


 - Is RoR here to stay?


 I'd say the adoption and the momentum is going to keep it in swing for 
 quite a while, how long? no clue.. I mean, back in the day Struts was 
 the thing (bleh), and it's slowly becoming defunct. Can you be 
 productive in RoR, sure, can you improve it? Sure, it's all about 
 tastes.. but if you want something in the terms of an independent report 
 on how great it is, I can't help. I've used it, it's worked for me on a 
 quite large intranet application, but nothing is the be all end all.
 

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


 It shouldn't be able moving people from, to d's implementation, it's 
 about providing a strong stack of development tools to allow people who 
 want to code in d on the client, on the server and indirectly, for the web.


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


 More enterprise speak?


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


Oh, I know all about managers *knowing more* :), so no worries, just 
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?


 I'd say the adoption and the momentum is going to keep it in swing for 
 quite a while, how long? no clue.. I mean, back in the day Struts was 
 the thing (bleh), and it's slowly becoming defunct. Can you be 
 productive in RoR, sure, can you improve it? Sure, it's all about 
 tastes.. but if you want something in the terms of an independent 
 report on how great it is, I can't help. I've used it, it's worked for 
 me on a quite large intranet application, but nothing is the be all 
 end all.


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


 It shouldn't be able moving people from, to d's implementation, it's 
 about providing a strong stack of development tools to allow people 
 who want to code in d on the client, on the server and indirectly, for 
 the web.


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


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


Yeah, fair enough.
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


For the record I've been on both sides of the fence, tri weekly meetings 
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.



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 






snipped

 1 & 2 depend on a couple of things in relation to RoR.

 Since classes absorb the schema of the table they represent, if a data 
 type of a column changes, it can handle it in the means of generic 
 find, save, etc. However, if there is logic in the code that depends 
 on that type, it's obviously going to fail.


 
 Makes sense. So if all Ruby does is e.g. display a column, which I 
 assume is a generic operation with uniform syntax over all types, the 
 type of that column could be anything. If, on the other hand, Ruby does 
 some math against a column, and that column changes from number to 
 string, runtime errors would ensue.
 


Exactly, access is transparent as long as you don't use it as the 
previous type.


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


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


 Again with the addition of a column, it's absorbed by the class 
 (meaning that there is a property generated at runtime for access to 
 the class implementation.


 
 Alright. And are there any operations (e.g. "print all columns") that 
 will naturally encompass the new column too?
 


Yeah, you can get a hash of all columns, and you can access it via its 
property as aforementioned.


 If a table is added RoR doesn't care about it, but you can't use it in 
 an association, due to the fact that the machinery needed for 
 represented associations needs to be generated against that new table.


 
 Interesting. So here's a limitation that might be addressed. Do all of 
 today's database engines (e.g. mysql) offer structure inspection (e.g. 
 "enumerate tables in this database", "enumerate fields in this table"...)?
 


Though there may be some slight differences between what you *can* get, 
  I'm fairly sure that most/all databases have a metadata implementation.


 So how does it handle changes? Pretty blindly, as long as your changes 
 don't change any logic you've predetermined into some code. including 
 associations (like belongs_to (where you've changed the name of the 
 foreign key)

 Bonus Question:
 Rails is pretty ignorant of the relationships defined in the database 
 itself DHH (author of RoR) has his reasonings listed here
 http://www.loudthinking.com/arc/000516.html


 
 Interesting. I happen to disagree with the author, and the "you'll have 
 to pry that logic from my dead, cold object-oriented hands" part 
 definitely sets off a blinking red LED somewhere, but I'm not a DB 
 expert nor a Ruby expert so possibly I'm even misunderstanding things.
 


I think they're taking a simplicity route when it comes to this (I can't 
read minds, but I'm assuming so) and there's some things I don't like 
about it either ~ namely you need to be explicit about validating a 
variable that the database provides you information for.

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

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


 I'm not even thinking of stored procedures as logic vehicles. All stored 
 procedures I've dealt with were little more than simply stored views 
 (SELECT statements). If I want to see customer phone numbers and their 
 orders, I'm glad to let the database do that efficiently by doing an 
 inner join and passing me the information in one shot, instead of having 
 me look at the two relevant tables for the sake of object orientedness. 
 To say nothing about data integrity, which is best taken care of at the 
 database level.
 
 The whole idea of manipulating data at table level and compulsively 
 delaying absolutely all meaning to the application level reminds me of 
 dBase and the 1980s.


Keep in mind that you can eager load other tables as you go through find 
methods, this allows you to either pull from the single table, or pull 
all related tables (while RoR writes an innner join behind the scenes)


 
 Anyhow, what I think might be good for most people is to write a SELECT 
 statement that does something, and have the columns of that SELECT 
 automatically available for further processing. I understand RoR doesn't 
 do that.
 


(not directly (that I recall), however you can define your own where 
clauses through the find methods generated on each model class.

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

The example above generates the where clause behind the scenes using 
that approach, lil tidbit :)

 I have read about hacks to get procs to work under oracle, though I 
 really haven't invested any time to the situation, as I've never used 
 the db (firebird mainly)

 (Not Defending his choices, nor am I an authoritative voice on RoR, 
 besides the couple of patches back to it, I'm just a user - though 
 limited as of late).

 If these answers don't answer what you're looking for feel free to let 
 me know


 
 Thanks, the answers were exactly to the point. By and large, I'm 
 interested in seeing strengths and limitations in the RoR approach, and 
 making an impression whether a more static approach would make a big 
 difference (better DB <-> code binding, better error detection, faster 
 execution).
 
 After all, the approach wouldn't even feel much more static: with rdmd, 
 fast compilation, and the bang syntax, D can pretty much have the feel 
 of an interpreter.
 
 
 Andrei


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

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

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


In this context, yes. Matter in fact there is several implementations of 
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). 


In the interest of accuracy there's also yaml (an xml like language, 
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).


No, it's done with Ruby during run time, using Ruby's dynamic and 
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?
 


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


 No, it's done with Ruby during run time, using Ruby's dynamic 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?

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


 No, it's done with Ruby during run time, using Ruby's dynamic 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.


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


 No, it's done with Ruby during run time, using Ruby's dynamic 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.
 
 
 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).


 No, it's done with Ruby during run time, using Ruby's dynamic 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
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).


 No, it's done with Ruby during run time, using Ruby's dynamic 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).


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


 No, it's done with Ruby during run time, using Ruby's dynamic 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
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).


 No, it's done with Ruby during run time, using Ruby's dynamic 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.
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).


 No, it's done with Ruby during run time, using Ruby's dynamic 
 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