Hi, Actually having to use matterhorn I'm now looking at our database and saying wtf, and I think I can hear Josh slapping his head from California wondering what took me so long. JPA or not, we have some really weird stuff going on, and we clearly need to clean it up.
How much is that going to anger other folks who have written scripts against the db for custom work? For instance, we have some nice expanded forms, like CAPTURE_AGENT_STATE, or HOST_REGISTRATION. Then we have some stuff that is shortened for no clear reason, like SCHED_METADATA. We have some tables with curious prefixes (MH_ROLE, MH_ROLE_MAPPING, MH_USER). Then, for reasons I can only attribute to insanity, we mix case of columns within a table: mysql> DESCRIBE JOB; +------------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------+--------------+------+-----+---------+-------+ | ID | bigint(20) | NO | PRI | NULL | | | CREATOR | varchar(255) | YES | | NULL | | | ORGANIZATION | varchar(255) | YES | | NULL | | | STATUS | int(11) | YES | | NULL | | | PAYLOAD | longtext | YES | | NULL | | | DATESTARTED | datetime | YES | | NULL | | | RUNTIME | bigint(20) | YES | | NULL | | | instance_version | bigint(20) | YES | | NULL | | | DATECOMPLETED | datetime | YES | | NULL | | | OPERATION | varchar(255) | YES | | NULL | | | DISPATCHABLE | tinyint(1) | NO | | 0 | | | DATECREATED | datetime | YES | | NULL | | | QUEUETIME | bigint(20) | YES | | NULL | | | PARENTJOB_ID | bigint(20) | YES | MUL | NULL | | | creator_svc | bigint(20) | YES | MUL | NULL | | | ROOTJOB_ID | bigint(20) | YES | MUL | NULL | | | processor_svc | bigint(20) | YES | MUL | NULL | | +------------------+--------------+------+-----+---------+-------+ (what the heck is an svc??) Sometimes we decide to use underscores to separate words in column names, sometimes we decide to save a byte (2 for you unicode folks). For instance we have CA_METADATA, EVENT_ID as columns, then RECURRENCEPATTERN, SERIESID in *the same table*. On top of it, null seems to be in for our tables, as lots of them seem to be filled with nulls. Anyone interested in coming up with a more clear guideline (or do we have one that just isn't being followed) for future releases? I'm willing to help audit the structure and file bugs if people are amenable to fixing the issues and cleaning up the tables for our next release. Thoughts? Chris _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
