DBA responsible for code going into database
Robert, September 01, 2009 - 1:33 pm UTC
Hi Tom,
<If the DBA was a developer that became a DBA...>
Do you mean 'database' developers or Java developer? (i.e. to be qualified to review Java code (insofar as the Java code affects the database))?
My position is that the Dba is responsible and accountable for what goes on in the database, and as such has an 'interest' (stake) in *all* code that is either stored in the database and/or affects the database (e.g. calls initiated from Java code)... and should therefore 'inspect' it (code review).
Thoughts?
Thanks,
Robert.
September 01, 2009 - 5:48 pm UTC
you don't have to be qualified as a java programmer to validate database interaction code. You do however need to have a developer mindset.
I didn't say they had to be a java programmer, they have to be able to understand algorithms, approaches, techniques and the right way to accomplish something against the database.
That does not describe all (some might even say it does not describe most) DBAs
Robert, September 01, 2009 - 6:45 pm UTC
A reader, September 02, 2009 - 10:05 am UTC
In general a person performing a code review must posses following knowledge in my opinion.
1. Coding standards followed by the organization
2. Functionality of the business that the code is implementing.
3. Technical expertise of the technology the code is written in.
I don't think all the DBA will satisfy the first 2 points.
For me a correct person to review the code would be some one who has been involved in the development before.
We do peer review all the time. We just exchange our code within developers and review it as a first level review. Its always effective.
There must be a reviewing objective. You must define that first. Why you are reviewing? What is the purpose? That must be defined first, once you do that you can easily identify the person suitable for the job.
September 02, 2009 - 11:09 am UTC
1) not necessarily - that can fall to someone else in the room. Code reviews many times do not show code at all - they show psuedo code and algorithms - approaches.
2) probably, not 100% necessary if you are there to review the approach to using the database.
3) no, not really. Algorithms and approaches can definitely be analyzed by someone not having that.
And if you think the DBA doesn't understand the business - I think you are working with version 6.0 DBA's (dba's who haven't changed since version 6 of oracle in 1993). The DBA's I meet in general have more business knowledge than most of the developers - they (the DBA's) managed the database and applications - they have a very broad view of the business, developers tend to be myopic in their view of the business - they work on an application - not all or many applications.
... For me a correct person to review the code would be some one who has been
involved in the development before. ...
you would be wrong, the best reviewers are those that come from the outside, they are not smart enough about the application to let something slide - if they see something confusing or not clear - they will ask. If someone is too close to the code - they make leaps of faith, they do not question.
I could (i do) come in a do code reviews, architecture reviews of applications I've *never every seen before*. And it works just because of my lack of knowledge. I'm not afraid to ask a dumb question - because I have no knowledge base.
... We do peer review all the time. We just exchange our code within developers and
review it as a first level review. Its always effective. ...
I believe you are kidding yourself. Peer review is typically not critical review. If you want a good critical review - get five people that do not like you. They'll find issues with your code - trust me.
Excellent Discussion
Adarsh Kumar, DBA, September 02, 2009 - 1:15 pm UTC
I agree with Tom the code review should be done by the peers
Also It is good idea to Involve a DBA from the beginning of a project so that DBA can help during the Database Design decisions as Tom pointed out DBA's has broad business knowledge and he knows what the other Groups & Projects are doing , or how a specific issue was resolved by the other groups.
That will reduce any unnecessarily surprises for DBA¿s because it is very hard to change the design once the project is almost done .
Thanks
Adarsh Kumar
September 02, 2009 - 1:46 pm UTC
well, re-read my last sentence right above...
I would like my code reviewed by people that know more than I do about something - suPEERior if you will.
.. Also It is good idea to Involve a DBA from the beginning of a project so that
DBA can help during the Database Design decisions ...
Actually - it is not just a good idea, it is (in my opinion) a mandatory idea.
Code review by Java Developers
Rajesh waran, September 03, 2009 - 5:19 am UTC
Tom,
Even we have a simillar scenario in our project. once the development is completed
the code review will be done by a person who is highly skilled in Java.
During Code review he used to ask one question by pointing out any query in a plsql package " What will happen if Database crashes while executing this query ?"
I would like to know answer from you. Please help.
September 03, 2009 - 7:55 am UTC
tell him "the client code will get an error, duh?"
tell him "same thing that will happen if during a file read, the file system failed, the client code will get an error"
David Aldridge, September 03, 2009 - 9:48 am UTC
>> " What will happen if Database crashes while executing this query ?"
My tuppence ...
That seems like a very good question actually, bearing in mind the propensity of developers to abuse commit by over using it. I think that the developer ought to be able to explain/demonstrate how the code is structured so that the instance recovery restores the database to a "business consistent" state, in the sense that there must be no "fractions of transactions" present (eg. no invoice headers without invoice details due to a commit being issued after the header record was inserted, followed by a system failure before the invoice detail insert was commited).
This is a big problem in DW ETL processes due to the high number of implicit commits when we use leverage DDL statements (partition exchange etc). Recovery from a system failure partway through a load is not trivial, and the same would apply to bulk processing in an OLTP environment I think. At some point you might not want instance recovery to rollback a huge set of table changes if there is a failure, so you have to provide code paths for picking up part-way through the process.
OVERwilling to COMMIT
Duke Ganote, September 03, 2009 - 10:40 am UTC
A reader, September 03, 2009 - 12:53 pm UTC
What will happen if Database crashes while executing this query ?
I recently came across a situation where the developers assumed that every connection attempt to the database will be successful and did not code an exception handler. Due to underlying configuration, the connection attempt sometimes failed on first attempt when idle for a long time, being successful on second attempt. The code did not handle the situation gracefully and logged the ora-xxxxx error and failed. After long tussle, the solution was to code an exception handler to retry the connection attempt. If only someone had asked the question during coding...