October 26, 2010 at 9:27 pm
Comments posted to this topic are about the item Writing Nearly Codeless Apps: Part 4
October 27, 2010 at 1:09 am
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
October 27, 2010 at 2:57 am
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
October 27, 2010 at 6:39 am
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
October 27, 2010 at 7:15 am
How is writing SQL building routines different from writing C# or Java code building routines?
October 27, 2010 at 8:56 am
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.
October 27, 2010 at 9:07 am
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.
October 27, 2010 at 9:30 am
(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.
October 27, 2010 at 9:39 am
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.
October 27, 2010 at 9:42 am
Phil Factor (10/27/2010)
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.
I'll be bold enough, and not for the first time, to predict that SSD will finally be understood to be the tool which supports BCNF/5NF (and not just a tool to speed boot). With such "complete" schemas, code generation from same is fully feasible. After all, as Date and Pascal have asserted, "a row *is* a business rule". Celko has also published "Thinking in Sets", which explains the use of auxiliary tables. Again, with such on SSD, performance is no longer an issue (modulo that one could get similar performance on rust with hundreds of short stroked parts).
October 27, 2010 at 10:00 am
RobertYoung (10/27/2010)
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.
RAP does not presume to actually alter your tables for you, and in fact other than providing a preprocessor to help enforce the consistency of primary keys and status fields, it is not involved in the process of schema generation. The kind of capability you describe transends even modern schema design tools, which generally do nothing for you other than generate the new DDL after you've changed the schema.
In order to preserve your data and make the kinds of new-field-initialization decisions you describe requires intimate knowledge of the purpose of the fields. Until such time as we have schema design tools that understand the intent (and not just the pattern) of your design, this task will need to be done by hand.
Similarly, neither RAP nor any other design tool that I know of would have the ability to modify your business rules and your UI in accordance with your schema changes. These sorts of changes could be made only by a comprehensive application design tool that truly understands what you are trying to do. Such a thing could sit on top of RAP, but it is well beyond the scope of RAP.
What RAP does do is to relieve you of the nightmare of trying to track down all the places in the database and the data layer that are impacted by your schema change. It does this by simply and comprehensively regenerating all the code it originally generated when you created the app.
October 27, 2010 at 10:54 am
Bob the Mushroom (10/27/2010)
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.
Right now RAP is pretty tied to its object name conventions. RAP is delivered in source form so of course if you were inclined you could change its conventions. But as for getting rid of the naming conventions entirely, I wish you luck.
For example, what is "UserDelete"? It makes perfect sense if you already know what it is, but does everyone know what it is? My schema might contain a table called "UserDelete". Or "UserDelete" might be a stored procedure. Probably it isn't a function (because functions can't modify data) but what about "UserFetch"? Is that a function or a stored procedure? Or is that a table too?
Systematic code generation requires totally unambiguous naming conventions. If you try to create a code generator without using a RAP-like system of being totally unambigouous, I predict you'll end up with users who are generating identical names for different objects. In RAP, the odds of doing this are precisely - zero.
October 27, 2010 at 10:55 am
Boban Stojanovski-455883 (10/27/2010)
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: Please see my response to "Bob the Mushroom" above. -Dave
October 27, 2010 at 11:13 am
As mundane as this might seem, these three routines provide some dazzling capabilities:
Not really. A history trigger is a far better choice. The stored proc can only ensure that the archive table has values in synch if that stored proc is the only means used to alter the data. What if someone does it another way? A trigger will fire no matter what means you use to update the data.
Viewing 15 posts - 1 through 15 (of 59 total)
You must be logged in to reply to this topic. Login to reply