Weekblog: Day 1

I didn’t get as far as I had hoped to tonight, due to a variety of distractions – it was an impressive list of “things that get in the way of previous plans” (Work actually had work for me to do, then a stop by the Mosaic work site to check on some supplies, then dinner, then home to find the freezer has stopped freezing (due to a broken icemaker), then helping out Cat with some finance stuff so we can get our Mortgage application in. Ung!

Finally I sat down, and with The Time Machine on as background entertainment (not so good a movie – great for background noise – and what the heck is with Jeremy Irons? Is there no movie so bad he won’t act in it? Sheesh) – I got down to work.

There were some great comments from yesterday on how to handle historical triggers on database updates. There’s some challenges to using triggers (such as “who made this update?” – though using a ‘last updated by’ column on every record could fix this, I’m still not sure if it’s a good idea). Jonah pointed out also that using database triggers limits the portability of the database layer. Given that MySQL isn’t going anywhere, and that it’s getting more and more attention as an enterprise-level database system, I’m not that worried about it, but I am taking that into consideration.

Tonight though I needed to find something short term to work through, so I focused on how ‘notes’ are applied to registrants. In the past, I would make a “NOTE” entry in the history table. These NOTEs could be anything from just an informational note by the operator (“This person was nice”) to something important (“Paid by check”). Having NOTEs in history was “okay” but without filtering, it was hard to see operator comments in a meaningful way.

I also had a concept of ‘NOTICE’ records. These are essentially NOTEs to be displayed to the operator whenever a registrant logged in. They would show up as red messages on the registrant detail screen, and the operator would have to acknowledge the NOTICE before proceeding (that’s the theory – in fact there was no logic to enforce this). These NOTICEs were very, er, noticeable to the operator, and were great for things like “DO NOT ADMIT THIS PERSON UNDER ANY CIRCUMSTANCE” (yes, we had a few of them, and I know of one instance where the CONGO ‘NOTICE’ record actually did prevent them from entering the event. Yay!). Generally though they were used for innocuous things like “STILL OWES $25” or the like.

For v2, I’m seperating out the NOTICE / NOTES into a separate table simple called ‘Notes’. The option to making any note entry a ‘notice’ will be on the note creation, and it’ll just be a flag on the record. Also the record will keep track of when the note was created, and by whom, as well as when it was acknowledged, and who acknowledged it.

The basic DAO structure is there, as is the data object, and I’ve created the schema file for it as well. Nothing is wired in yet, but I’m also still noodling around how I want the record to look, so I’m sure there’ll be more work moving forward.

The other bit I did tonight was trying to squash a problem I’m having with the JDBC connection pooling. I’m using the C3PO connection pooling tool, and if CONGO has been idle for a while, I’ll get a connection communications failure. Googling around hasn’t showed me anything immediately obvious, though others have said they’re having the same problem. What I’m trying now is adding some auto reconnection options to the JDBC connection string, so my c3po setup now looks like this:

private void configurePool() {
logger.debug("Empty connection pool, recreating...");
ComboPooledDataSource cpds = new ComboPooledDataSource();
try {
cpds.setDriverClass( "com.mysql.jdbc.Driver" );
} catch (PropertyVetoException e) {
e.printStackTrace();
}
cpds.setJdbcUrl("jdbc:mysql://localhost/congo?autoReconnect=true&autoReconnectForPools=true");
cpds.setUser("root");
logger.debug("Initted.");
applicationMap.put("cpds",cpds);
}

I won’t know if it’s working yet until I idle long enough to force a timeout. I’ll let ya’ll know.

About

A wandering geek. Toys, shiny things, pursuits and distractions.

View all posts by

7 thoughts on “Weekblog: Day 1

  1. Jeremy Irons is simply following an old British acting tradition: always keep working! Other British actors who got their start on the stage follow it, too-Michael Caine, for instance. (The Law of Conservation of Michael Caine dictates that for any good film he’s in, he must appear in a film that is bad. The quality of the films must balance out.)
    Basil Rathbone and Boris Karloff used to do the same thing, and they convinced Vincent Price (who was from St. Louis) that he ought to do that after they all appeared together in The Tower of London.
    (I learned all of that from the book his daughter wrote.)

  2. @Marty – that is fascinating, thank you! On the list of actors that of this ilk, Michael Caine definately shows up 9on the list. I was also adding folks like Malcom MacDowell, who seems to have his share of awful movies.

  3. Always thought there should be a ‘type’ field on notes… so say there’s a class of ‘payment’ notes, those could have a consistent flag (maybe an int lookup table). Notes wouldn’t -have- to have a type, but the more that had them, the easier it would be to filter programatically, or add new features through the use of the table. Thoughts?

  4. @Points – I thought about that a bunch. I think I’ll have a simple flag of “show this on the registrants screen” (and maybe another one of “this is not con specific” – but that may go with the ‘CID=0’ thing, i have to think on that). But I also don’t want the NOTES table to get too complex and start infringing on what the history table does.
    I think initially i’ll implement just a boolean for “this is a notice, show it on the registrant screen”, with the option of expanding it later. That’s the wonder of DAO’s, I can make structure and functionality changes a lot faster.

  5. Will it be possible to edit notices, or delete them, or at least turn a NOTICE into a NOTE, for when it’s no longer relevant? It won’t erase from history, but it would be nice for the operator to not have to parse through several lines to see the current state of things.

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.