Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Writing Nearly Codeless Apps: Part 4 Expand / Collapse
Author
Message
Posted Tuesday, October 26, 2010 9:27 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
Comments posted to this topic are about the item Writing Nearly Codeless Apps: Part 4
Post #1011241
Posted Wednesday, October 27, 2010 1:09 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, January 7, 2011 3:17 AM
Points: 21, Visits: 24
Hi David,

How configurable are the object names? I know that it's initially unlikely anyone will bother to look into the database if it's getting auto-generated, but auto-generation isn't necessarily an excuse for failing to meet coding guidelines. Anyone who works with me and creates a stored procedure called SPTBadmUser_Delete is going to get it in the neck pretty quickly - exactly the same as any developer who creates a DataSet variable using a ds- prefix. YMMV, but in my opinion UserDelete gets the point across perfectly succinctly, possibly more rapidly for a human reader. I don't need the name to reflect the fact that it's a stored procedure that acts on a table, just the object being modified and the action being performed on it.

Cheers,

Bob
Post #1011300
Posted Wednesday, October 27, 2010 2:07 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, July 14, 2014 9:16 AM
Points: 59, Visits: 95
Totally agree with Bob.
What I also didn't like on generated code from RAP is the code style how procedures are defined.
I use my codesmith templates for this job, and not just for creating stored procedures.

Boban.
Post #1011324
Posted Wednesday, October 27, 2010 2:57 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:19 AM
Points: 577, Visits: 2,503
The weaving loom, the piston engine, and the computer are examples of machines which, through the use of previously unimaginable repetition, relieve humans of unimaginable drudgery. If the automation of repetitive tasks is not the greatest of all human technological advances, it must certainly rank near the top.

How strange then that people who surround themselves with computers are so eager to resign themselves to enormous amounts of highly repetitive and error-prone hand coding, which could easily be automated with just a little systematic effort. One such task is .....


I was hoping you'd got all this sort of messianic language out in the previous parts. Those of us with gray whiskers have heard its like, many times. You have some good ideas, but surely they'd have more impact if you just let us have the facts about what the system will do. Certainly, it is wise to read up on the history of this type of application as there have been many, many attempts to circumvent the need for coding. This is by no means the first. I remember making quite a bit of money through retailing a piece of software in around 1982 called 'The Last One' ( http://teblog.typepad.com/david_tebbutt/2007/07/the-last-one-pe.html ) that used very similar language throughout the manual. It promised to be the last piece of software you'd ever need as it allowed you to write, in a simple '4 GL' language, the entire database, auto-generated in Microsoft Basic and the front-end application as well. Accounts, payroll, inventory, the lot. I've kept a copy of the manual as a souvenir. As far as I remember, 'The Last One' lasted about six months as a commercial success, though the ideas developed in other products in the late 1980s.


I'm all in favor of relieving the need for repetitive coding in SQL, and I've published some articles on the subject, but I'm convinced, after many years of using these sorts of techniques, that there are limits to what can be achieved this way.



Best wishes,

Phil Factor
Simple Talk
Post #1011343
Posted Wednesday, October 27, 2010 6:39 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, May 11, 2011 10:52 AM
Points: 6, Visits: 84
I'm curious how your tools handle changes to the schema once your DB is in production and your tables are populated. What is the process for adding a new column or for breaking one table into two tables or factoring some columns out of a table into a new related table? These are the types of real DB life-cycle maintenance tasks that I've found challenging to do with any tool or framework.

Thanks,
-Dave
Post #1011473
Posted Wednesday, October 27, 2010 7:15 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, August 8, 2012 7:27 AM
Points: 4, Visits: 18
How is writing SQL building routines different from writing C# or Java code building routines?
Post #1011509
Posted Wednesday, October 27, 2010 8:56 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
david.avraamides (10/27/2010)
I'm curious how your tools handle changes to the schema once your DB is in production and your tables are populated. What is the process for adding a new column or for breaking one table into two tables or factoring some columns out of a table into a new related table? These are the types of real DB life-cycle maintenance tasks that I've found challenging to do with any tool or framework.

Dave: Because RAP looks into the database (rather than your original and perhaps unchanged schema design), it can always regenerate all the code that corresponds to the tables whose schemas you have changed.

So the procedure is: 1) alter the schema using any method you choose, so long as you don't modify or eliminate any of the RAP-required fields (remember you must alter both the "current" table and also the "archive" table in each table pair; then 2) run the RAP database generator, unchecking the option to generate the "archive" table - this rewrites all your access routines, and finally 3) regenerate all your data-layer objects using the database generator, and copy the generated code verbatim into your application's data layer (just like you did the first time when creating the app).

That's all there is to it. In a few seconds RAP regenerates both the routines in your database and the objects in your application data layer, and all the code is error-free.
Post #1011615
Posted Wednesday, October 27, 2010 9:07 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
Phil Factor (10/27/2010)
I was hoping you'd got all this sort of messianic language out in the previous parts.

Well taken. I am not a big fan of messianic language either. However I've found that I must strike a balance between my normal stoic "just the facts ma'am" nature and the real world. In the real world, people don't read stoic articles.

But actually there is another reason why I use this sort of language. I have found over years and years of trying to talk to people about the benefits of consistent, systematic design that most of them just don't get it, even with all the analogies I try to use (messianic or otherwise).

I doubt seriously that even one in ten programmers imagines that his job and indeed his entire industry is a plum candidate for takeover by any competitor having a serious focus on efficiency and product quality (both of which derive from systematic design). I have this doubt because I so rarely encounter either efficiency or product quality in any of my gigs. So apparently American industry (where I work) doesn't attach much significance to either.

So I keep trying to get the message across. The language is just one of my methods. Even with all of this, the attitude of most people I encounter is "so what?" Of course, that was the same attitude that Deming encountered when trying to sell the American auto industry on the same ideas 60 years ago. Too bad for the American auto industry.
Post #1011629
Posted Wednesday, October 27, 2010 9:30 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 5:49 AM
Points: 76, Visits: 231
(Quoting inserted the previous post, for whatever reason!)

So the procedure is: 1) alter the schema using any method you choose, so long as you don't modify or eliminate any of the RAP-required fields (remember you must alter both the "current" table and also the "archive" table in each table pair; then 2) run the RAP database generator, unchecking the option to generate the "archive" table - this rewrites all your access routines, and finally 3) regenerate all your data-layer objects using the database generator, and copy the generated code verbatim into your application's data layer (just like you did the first time when creating the app).

That's all there is to it. In a few seconds RAP regenerates both the routines in your database and the objects in your application data layer, and all the code is error-free.


The long standing issue with schema changes (code generated or otherwise) is what to do with existing table data. With code generation, there really does need to be a hard and fast rule: if Sally Business Analyst wants a Foo column added to the Bar table she has to either identify the default value or accept that the column is Nullable. Sally, most often, hasn't a clue what the answer is, either way. Generation doesn't create the problem, but when coders are in charge, the problem keeps getting fobbed off into byzantine code loops. Generation demands an up front answer. The needy BA's of the world don't like having to be explicit.
Post #1011646
Posted Wednesday, October 27, 2010 9:39 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, July 24, 2013 3:24 PM
Points: 37, Visits: 68
I am with you 100% on this. I too have gray whiskers and would have named things differently, but the key is to have consistent, reliable code that is easy to create and self audits.

I have worked with many otherwise sharp people who wouldn't be bothered even reading your article, let alone wanting to implement something like it.

I doubt this is entirely American, but it does seem to be our culture to be slow to catch onto good ideas.
Post #1011657
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse