Timeline for Software rewriting alternatives
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 7, 2012 at 13:38 | vote | accept | weston | ||
| Aug 6, 2012 at 13:03 | comment | added | user1249 | If you want to replace the database, you must do this anyway. | |
| Aug 6, 2012 at 11:15 | comment | added | superM | @weston, you're welcome )) | |
| Aug 6, 2012 at 11:12 | comment | added | weston | Thanks, I think this is a sensible way forward. It's refactoring the project to how it should have been done in the first place WRT to persistence, then it's a simpler step to change DB, and later replace the business logic if required from a recriutment point of view. | |
| Aug 6, 2012 at 10:53 | comment | added | superM | Since you've determined to re-write the project, and you've alreadt faced the difficulty of modifying a lot of files to access the DB correctly, I suggest you do this once again and forget about it forever. You'll have to change those files anyway | |
| Aug 6, 2012 at 10:50 | comment | added | weston | I like the idea, but I think introducing an intermdiate layer would mean modifiying the 90% of 756 files/classes that access the db. A large proportion of the files (150 or so) probably do nothing but manage db tables, so I guess these files would sit in the legacy db implementation module. | |
| Aug 6, 2012 at 10:40 | history | answered | superM | CC BY-SA 3.0 |