Project

General

Profile

Actions

Bug #2497

closed

Denorm utility incorrect in order of statements (based on tables, not sequence)

Added by Michael Lee over 17 years ago. Updated over 17 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
misc
Target version:
Start date:
07/20/2006
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
2497

Description

I think the denorm utility updates after an XML load from table-to-table. This is incorrect. It should go in the order of the numbered dnrm- statements in SQLStore, NOT BY TABLE.

MLee should check that this is indeed happening and possibly suggest a solution in the java utility.

Actions #1

Updated by Michael Lee over 17 years ago

I have confirmed that this is indeed happening-- the ordering gets messed up because each table is run in the order of tables (what order of tables, I don't know). Further, it seems that they are sorted in alphabetic order, not in order of the numeric keys in SQLStore.

So, the keys in SQLStore are like so:
dnrm-[table]-[sequence #]-[human readable description]

We should run all of the denormalizations, but in the order of [sequence #] not grouping by tables. The offending code is here:
vegbank/src/java/org/vegbank/common/utility/DenormUtility.java
The method init() is called and it "sorts" by table then sequence ID. This is called by LoadTreeToDatabase method runDenorms(), which itself loops through tables, but instead should call a new method in the DenormUtility which runs through all denorm statements in order, rather than requesting each table.

One SQLStore statement is wrong, I'm removing that in SQLStore now.

The implications of this is that plots are not properly denormalized and thus are embargoed (at least partly) by default.

Actions #2

Updated by Chad Berkley over 17 years ago

the denormutility now builds a vector of all of the keys in the sqlStore.properties file and sorts them by the sort value. When a subprocess needs to run denorms, it can now just "queue" a tablename. after all of the tables it wants to denormed are queued, the execute() method is called and denormUtility first orders all of the queued tables in the order they are in in the ordered vector, then runs the denorms. This appears to be working and it makes denormalization much more effective (since now it's running the sql statements in the order in which they were designed to be run).

Actions #3

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 2497

Actions

Also available in: Atom PDF