Bill Roper (billroper) wrote,
Bill Roper

That Big Project At Work

I love it when a plan comes together. Unfortunately, that sometimes means abandoning Plan A and proceeding briskly to Plan B. :)

You see, right now, we key the account rows in our system using a 32-bit integer key which we break down into three segments and display as a string separated by periods. In the new, improved system that I'm working up, we'll key the account rows with an arbitrary string, but it can still have up to three segments which mean pretty much what the old segments meant.

An old account when displayed might look like "1000.00.000" or "2000.01.100". If you specified the third segment (for subaccounts) as non-zero, you had to specify the second segment (for related accounts) even if it was zero. If the last two segments were all zeroes, you didn't need to display them at all, so "1000.00.000" was the same as "1000".

The problem is that the old system -- as you see above -- required you to stick "00" into the middle segment if you wanted to use the last segment, which specifies our subaccounts. Not all accounts in the system will have a middle segment, but they may still need to have subaccounts.

And I think that constructs like "1000..000" are plug ugly. Nor do I want to force the user to put some arbitrary "null" character in between the two periods. And if I don't do that (require two periods if a subaccount is specified), then I can't figure out in an arbitrary string whether the user intended to specify a subaccount segment or a middle segment.

So I've decided that the format of names will use a period to separate the middle segment and a colon to separate the subaccount segment. This way, when I look at "1000.00", I can uniquely say that the prefix is "1000" and the middle segment is "00" and there's no subaccount segment; while "1000:000" says that the prefix is "1000", there's no middle segment, and the subaccount segment is "000".

That's what you'll get on conversion, anyway. New templates will likely use real names rather than numbers.

And I'm hoping that our users will learn to like "1000.00:000". :)

The Plan B part of all this is that I kept trying to figure out how to support and correctly parse an account name that contained one period into three parts, one of which was blank, if only I knew which one. I had an ugly little scheme that involved storing IDs with three separate strings which I spent several days mucking around with.

All of that code is now being pulled out and replaced.

And I'm staring at about 450 compilation errors again, which is pretty much where I was when I shifted to Plan B.

Tags: musings, work

  • Closer To Fine

    So the cabinets went in today, which is good. There are, sadly, two problems. First, there is a measurement glitch which resulted in the cabinets…

  • This and That

    Gretchen felt pretty lousy today in the wake of the COVID shot and spent most of the day huddled under a blanket on the couch. Neither kid ended up…

  • That Was the Day That Was

    We finished packing out the kitchen last night around midnight and got way too little sleep last night. Then it was up early this morning so that the…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded