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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
February 12, 2007
Re: RoR, Judge Judy, and little old ladies
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
1 2 3 4
Top | Discussion index | About this forum | D home