Meta Manager

Work is on my mind this morning.

Since this blog is about whatever I'm thinking about, I've decided to allow myself to write about my work. If I had any readers, I'd worry about boring them.

That's not yet a problem, and maybe it won't be as boring as I fear.

So here it goes.

I've been writing a database program that is universally useful. Now specifically, it is only the data-entry portion of the application that is universally applicable. It works quite well and I'm starting to deploy it to various offices (customers).

It does this by serving as a data modelling tool that automatically creates tables and relations, and then has a user interface that allows data entry into any of these tables and relations. All the information about what sorts of things will be tracked, and links between those things, is stored as metadata.

Even though I'm still early in the beta (bug stomping) phase, I've already found out that one of the trickiest things for us (the vendors) is keeping track of the metadata as it's needed in each office.

Each office differs, sometimes slightly, sometimes dramatically, in their data needs and interests. As I go from office to office, distributing updates, bug fixes, and so forth, I'm finding that these differences are beginning to step on each other.

Office Alpha needs to track A, B, and C. Office Beta tracks A, B, and D. If alpha improves the way it tracks B, beta wants to benefit from that development, but if alpha stops tracking A, beta doesn't want to lose that ability.

So I need another application, just to keep track of what each office is doing, and to manage what changes to distribute to each office.

This is so important, that it's what I'm devoting myself to for the rest of the week.

Here's how I'm going to do it:
1. The Metadata Manager (MM) will have it's own version of all the user system (USys) tables (that's where I store the metadata in the apps). These MM USys tables will also have an Office column where I'll tag the row with the office that owns it.

A. I've been debating whether to allow a many-to-many relationship between offices and metadata entries. That way, I could indicate that Office Alpha and Office Beta and Office Gamma use Entity Type A, with Traits Ab, Ac, and Ad-f, but only Office Gamma uses Trait Aa. My problem with this is that each metadata row has multiple attributes. Even though several offices may use the same entity type or trait, they may use it in slightly different way (having different data domains, for example, or allowing multiple values at one office and not at another, or having different default values, etc.). So, no. There will be no sharing. Once a metadata item is assigned to an office, it belongs wholly to that office. This may result in some duplication between offices, but it's easier to keep things straight this way.

B. I'll need a way to add new metadata items as sort-of candidates. These are items that have not been deployed to any office, but should be. These items should be tagged for deployment to any number of offices. Once deployed to an office, the item will appear in the offices metadata set, and the candidate entry will be marked as deplooyed to that office. After that, it is managed at the metadata level.

2. The MM must allow me to compare my record of the metadata for a given office with what exists when I visit the office. I travel from place to place, taking the MM with me. Once I use the MM to check the working copy of the app on the client's network, I should immediately see any differences. Metadata at the office can have been changed, deleted, or added. The data in the MM should be marked as changed and archived somehow. It should then be synchronized with what is on the client's network (the production copy).

3. It's becoming obvious to me that I'm really creating a version control system. I should research how that's done in programs like Git and learn what I can.

What I really need is for this to be a quick-and-dirty tool that is easy to create, easy to understand, and easy to manage. I've no time for a lengthy development process, and no time to be distracted from debugging the main app and finishing the reporting tool that goes with it.