As you may have noticed in my last post, I had plans to complete the deletion logic yesterday. Though I did manage to do some research on the various auto-options, I didn't actually get any code written. Today I'm going to work on the coding.
To start, I have decided to change my foreign key constraints on all of my tables to cascade updates and set to null on deletions. Though this may obscure bug-searching later, I think it will be easier to handle null values than to handle SQL exceptions. Time will tell, of course. And this will probably necessitate some form of orphan searching in the future to clean up any data that becomes unreachable. I'm willing to take that risk to get this project finished in my required time frame.
Less than 30 minutes into coding the deletions, I ran into a bit of an oversight. I didn't really think out in advance how to determine equality. It seemed so simple and straightforward at the beginning that I forgot I need to create the equals() and hashCode() methods. Now I've gone to the work of having each method check one or more attributes of an object for equality when I could really have just coded these two methods in each class and others could just call on them. I don't really have time to seek out these codes I've made so will just have to live with the ungraceful and difficult-to-maintain way I've set it up. Perhaps a future release will improve upon this.
Forgetting these methods and having forgotten all the ins and outs of comparators, I'm going to have to have a very unpolished finished product in order to come in on time. I'm going to avoid the extra scope of making everything sortable for now and just get the down and dirty working. Sorting can be added in a future release as well.
You know what the saddest part of all this is? I probably could have cut out hours and hours of coding if I'd remembered my original plan of using database hits for a lot of these actions instead of trying to code and encapsulate them in Java objects. I created unique IDs for all of my tables so I would just need the ID (the primary key) to reference them from other tables, and then here I go trying to compare whole objects. Blech! What was I thinking?
Live and learn, I guess, which is really what I'm here to do. One thing I'm learning fast is that this stuff gets complicated rather quickly. Experience should help improve my ability to simplify things but I don't think I'm going to go into much coding professionally. It just gives me a headache to design at this level and I like to be a diverse IT person rather than specialized.
I am also noticing certain lack of consistency to my naming schemes that's starting to annoy me. For example, in Java, I've coded some of the IDs in caps and some in lowercase. It didn't seem like a big deal at the time, but now I'm really glad NetBeans gives me pop-ups so I can reference the right spellings. I'm also starting to see the value of programming to an interface - since many of my tables interact in the same way, it would really have helped to enforce consistency and remind me of my original design so I didn't get sidetracked on some of my methods.
All that being said, I've thrown together some usable (if not particularly smart or elegant) deletion methods and am now considering the main work of the recipes in the logic layer to be complete, at least as semi-functional skeletons.
I should probably start working on the meal plan portion and create all the same functionality, but like I said, I'm getting quite the headache with my failure to be consistent and don't really want to extend that. Also, I need to start creating a user interface so I can start work on my documentation. After all, my end-point for this project is not a fantastic, beautiful, professional piece so much as a skeleton that can be grown into a professional piece. At least that's how I'm viewing it.
When I say I'm going to start working on the User Interface, I totally mean that tomorrow I'm going to start working on it. I am totally fried tonight and don't expect to have much success by pushing forward in this state.
No comments:
Post a Comment