From: Li G. <lg...@th...> - 2007-08-29 02:22:57
|
As for the native SQL code mentioned by Amit in AddActivity.java, we found that it's done by Jim Kindon. Actually we dont know why he used native SQL script instead of using persistence layer (hibernate). Shall we refactor the code using persistence layer (hibernate)? Cheers and Regards! Gao Li "Amit Levy" <aa...@gm...> Sent by: mif...@li... 2007-08-24 16:31 Please respond to Developer <mif...@li...> To Developer <mif...@li...> cc gc...@gr..., Michael D Robinson <mdr...@th...> Subject Re: [Mifos-developer] The conflict cause by ACTIVTTY_ID been solved > As a contingent solution, we generate ACTIVITY_ID in the range from -1 to > -32768 for new reports. > In the future, we may need a better solution to handle automatically > genereted ACTIVITY_ID. Having a temporary solution is going to make it harder to change later. I think we should find good solution now. > The conflict caused by automatically genereted ACTIVITY_ID has been solved. > So now the test server can upgrade as usual. Using features with temporary solutions, whos replacements will likely involve significant db schema, or paradigm changes is bound to cause upgrade issues like the ones we already encountered. Finally, what I was hoping to reach in a furthur discussion of the initial code was that the use of AddActivity in this context is very dangerous. The reason is that it invokes native SQL code (as was built to replace SQL upgrade scripts). In general you should use the persistence layer (hibernate) to add elements to the DB. -Amit ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ |