Mijn dag-tot-dag logboek van de werkzaamheden die ik op profiler uitvoer.

HOME

Archives:

---------------------------------
- Profiler Logboek
- Werksessie 27-2-2001
- D.D. de Kerf
- PC06
---------------------------------

Zo. Lang niets meer gelogt, maar dat betekent niet dat ik stil heb gezeten. In tegendeel! Filterstellingen kun nu namelijk zonder problemen worden weergegeven (weliswaar nog met wat beperkingen, maar goed). Even kort achter elkaar de dingen die ik heb gedaan...
Allereerst heb ik natuurlijk de kopie van de lagenkolomweergave component die Edwin gemaakt had, bekeken. Ik had mij nog nooit echt verdiept in dit component en kon dus wel wat opheldering gebruiken. De code is vrij rechttoe rechtaan en het eerste wat mij noodzakelijk leek, was het vervangen van de lijst van laagweergaven (een lagenkolom geeft natuurlijk meerdere lagen weer) te vervangen door een lijst van lijsten van laagweergaven. Bij filterstellingen hebben we namelijk meerdere kolommen en elke kolom heeft zijn eigen lijst van laagweergaven. Vervolgens heb ik zowat alle code in het component bekeken en gewijzigd met de extra dimensie. Het resultaat was een kolom die er, tot mijn grote verbazing, precies zo uitzag als de kolomweergave met alleen de eerste kolom uit de filterstelling.
Dit bleek uiteindelijk mijn fout. Ik zorgde er namelijk voor dat de linker- en rechterkant van elke kolom binnen de filterstellingen kolom werden geschaald. Ik zette de nieuwe linker- en rechterkant echter al bij het aanmaken, terwijl er dan helemaal nog geen sprake is van breedte, omdat het component nog niet weergegeven is. Daarom bereken ik nu de linker- en rechterkanten van de verschillende kolommen op het moment van tekenen (dus in de DRAW). Ook sla ik de berekende rectangles op in de laagweergave componenten, omdat anders de selectie niet goed verloopt.
Vervolgens had ik nog een forse tegenslag. Bij het instellen van een nieuwe datainterpretatie of legenda werd het hele filterstelling weergave component aan de kant gezet en werd de kolom weer doodleuk een lagenkolomweergave. De reden hiervoor bleek uiteindelijk in de update code van btaClass_Profiel te liggen. Daar werd namelijk na het leggen van nieuwe koppelingen gekeken naar de orientatie van de kolom. Als de orientatie horizontaal was, besloot het profiel deze dan maar aan de lagenkolomweergave component te koppelen. Fout dus. Daarom heb ik de code gewijzigd. Nu wordt VOOR het leggen van nieuwe koppelingen gekeken welke weergavecomponent gebruikt wordt (kan ik zien in btaClass_KolomData). Na het leggen van de koppelingen worden de weergavecomponenten weer hersteld.
Tenslotte heb ik nog functionaliteit toegevoegd om de verschillende kolommen binnen de filterstellingen kolom van volgorde te veranderen en, indien gewenst, te verbergen. Ook dit bracht nog de nodige problemen met zich mee, maar nu werkt het allemaal vrij goed.

Status Quo: We hebben nu een vrij aardige filterstelling weergave component die meerdere kolommen in één kolom kan weergeven. De volgende (grote en kleine) punten ontbreken nog:
- Selectie: Je kunt netjes lagen uit verschillende kolommen selecteren. Als je echter vervolgens naar het kolommen eigenschappen dialoog gaat, wordt niet automatisch de geselecteerde kolom geselecteerd in het scherm. Dit is echter volgens mij ook zo bij de lagenkolomcomponent. Ook daar wordt niet de geselecteerde kolom in het eigenschappen dialoog geselecteerd.
- Schaling: De verschillende kolommen in de filterstellingen kolom worden geschaald naar de STATISCHE breedte van de filterstellingen kolom. Is er maar 1 kolom zichtbaar, dan is deze dus net zo breed als een halve filterstellingen kolom. Zijn er 2 kolommen zichtbaar, dan is elke kolom net zo breed als 1/4 filterstellingen kolom. enz. enz. Het mooiste zou een mechanisme zijn waarbij je in kan stellen hoe breed een kolom moet zijn en dat het component dan tegen profiler zegt hoe breed hij gaat worden. Dit is echter lastig omdat profiler daar nog geen rekening mee houdt. Dit betekent dus een hoop extra werk.

Dit zijn de punten die op het moment nog niet in orde zijn. Nu ga ik kijken of ik een beetje een zinnige datadefinitie op kan stellen voor filterstellingen.
posted by Davy at 07:21 [edit]

Mail van Davy aan Edwin, 20-2-2001, 13:57

Edwin,

IKolomWeergave heeft een functie getBoundRect. De
btaClass_GrafischeComponent implementatie hiervan is simpelweg het
teruggeven van m_EnclosingRect.

Volgens mij wordt deze functie ook gebruikt bij het tekenen van het
profiel (ookal weet ik dat ook de functie setBoundRect bestaat). Kunnen
we niet gewoon het component zelf laten bepalen of alles wel past, ja of
nee???

Dus wat we dan voor de filterstellingen weergave component moeten doen
is het volgende aanpassen:

- de setBoundRect aanpassen. We moeten dan wel bedenken wat we gaan doen
als de setBoundRect wordt aangeroepen voor een bepaalde breedte.. We
moeten bijvoorbeeld afspreken dat in de breedte van een normale
kolomweergave (die in de template instelbaar is) overeenkomt met 2 of 3
buizen. Zijn er meer dan 2 of 3 buizen, dan maken we de boundrect zelf
nog groter.
De post-conditie van setBoundRect verandert dus, immers m_EnclosingRect
is niet per definitie gelijk aan de parameter die is meegegeven
Of wacht even, gebeurt dit niet al??????

- de getBoundRect hoeft NIET EENS aangepast. Die geeft namelijk alleen
de member variabele terug

- de setLocatie moet m_BoundRect gaan berekenen en instellen.


Als mijn vermoedens correct zijn, hoeft de rest van het mechanisme dan
niet aangepast te worden...
posted by Davy at 04:51 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 20-2-2001
- D.D. de Kerf
- PC06
---------------------------------

(11:42) Zojuist (van 11:00 tot 10:35) met Edwin overlegt over de aanpak van de filterstellingen binnen Boris en Profiler. Over de modelwijzigingen in Boris waren we het roerend eens. Dit is ook mooi, omdat het boris mechanisme voor de data gaat zorgen die profiler in gaat lezen en vervolgens af gaat beelden (dat mag ik doen). Wat profiler betreft kwamen we ook aardig overeen. We hebben beslist dat er één component komt dat zelf meerdere typen buizen kan tekenen, in plaats van verschillende componenten die allemaal één type buis kunnen tekenen (dit probleem is gerelateerd aan het boris probleem: één specifieke kolomgroep per type buis of één type (kolomgroep) waarin je het type buis kunt aangeven. De vraag is echter nog of verschillende typen buizen ook verschillende kopgegevens hebben. Is dat WEL het geval (wat wij niet denken), dan moeten we deze hele aanpak (en wellicht dus ook de profiler aanpak!) herzien..

Hoe dan ook, we komen dus uit op één weergavecomponent dat meerdere buizen kan tekenen. Dit doet het ook allemaal binnen één kolom wat het voor de gebruiker stukken eenvoudiger maakt. Een probleem dat Edwin en ik hierbij zagen was wel de breedte van de kolom. Die staat dan namelijk niet vast. Een kolom moet dus kunnen zeggen hoe breed hij denkt te gaan worden en profiler moet deze gegevens kunnen gebruiken bij het tekenen van het profiel....
Een ander punt was de vraag hoe we het op gaan lossen met de kolomdata componenten. Op het moment heeft elke kolomweergave een relatie met één lokatie en een lokatie heeft een relatie met één kolomdata object. Mijn idee was om de meerdere kolommen op te slaan in één kolomdata object, ookal zijn het eigenlijk meerdere kolommen.... Edwin kwam echter met een (op papier) mooiere oplossing: een kolomweergave component krijgt een relatie met meerdere locaties en meerdere legenda-engines in plaats van met één. Dit klinkt als een ingrijpende wijziging, maar die valt enorm mee, omdat een kolomweergave WEL weet naar welke lokatie hij wijst, maar een lokatie zelf NIET weet aan welke kolomweergave hij zit. Dit is mooi, omdat de kolomweergaven buiten profiler vallen. De modelwijzigingen heeft dus 'an sich' geen invloed op het profiler mechanisme. Wel zal ergens de koppeling gelegd moeten gaan worden naar MEERDERE locaties (dit gebeurt ook in profiler). Ik zie hier een probleem omdat ik weet dat de logica in profiler vrij complex is, maar Edwin denkt dat dit reuze meevalt omdat de koppeling slechts op één plaats gebeurt (en dat klinkt ook aannemelijk).


Hoe we nu op korte termijn verder gaan is duidelijk. Ik kan niet inhoudelijk gaan werken zolang ik geen testgegevens heb (Edwin is nog bezig aan het Boris component en het Profiler inleescomponent voor de benodigde gegevens.. hij zal een component met testgegevens maken voor mij, op korte termijn). Daarom begin ik met een inventarisatie van de impact van de modelwijziging die op papier weinig impact heeft. Ik ben zelf echter bang dat deze meer impact zal hebben dan we vanuit het model kunnen overzien (immers, een model is mooi, maar het is wel een keer geïmplementeerd, waardoor de realiteit misschien niet 100% overeenkomt met het model) en zal daarom dus eerst gaan inventariseren...

Binnenkort meer gegevens over mijn inventarisatie ;-)

posted by Davy at 02:49 [edit]

Eerste overpeinzing over de filterstellingen

In verband met het toevoegen van de mogelijkheid om filterstellingen in Profiler weer te kunnen geven moeten we sowieso de volgende punten bijwerken:

1. Het inleesmechanisme
Profiler moet vanuit boris-bestanden (.bor) en/of vanuit de REGIS (?) database de gegevens kunnen gaan halen om de
filterstellingen weer te kunnen gaan geven. De gegevens die zeker nodig zijn, zijn de volgende:

- Aantal 'buizen' al dan niet in de gewenste volgorde en met de gewenste volgnummers.
In het discussiestuk over de definitie van grondwatergegevens wordt gesteld dat er een systeem zit in de volgorde van de
buizen en dus ook hun volgnummers. Ze zouden gesorteerd zijn op de diepte van het midden van het filter (de ondiepste eerst).
Dit is echter in strijd met wat Bram en Aleid ons hebben verteld (ik meen mij te herinneren dat iemand zei dat de volgorde
veranderd moet kunnen worden en dat de volgnummers al zijn ingevuld en wellicht gaten bevatten). Ik denk dat we er vanuit
moeten gaan dat de volgnummers al bekend zijn en dat deze moeten worden overgenomen. Anders is het vrij eenvoudig mogelijk om
zelf de volgorde van de buizen vast te stellen.

- De boven- en onderdiepte, de doorsnede (?) en het type van elk stuk buis (stijgbuis, filter enz.)
Als het om filters gaat willen we graag ook nog wat extra informatie weer kunnen geven, zoals de breedte van de spleten in de
filters.

- Eventueel de gegevens van de omstorting en de verbindingen tussen de buizen.

2. Het 'vertaal' gebeuren (LegendaEngine)
Profiler vertaald de rauwe gegevens die het ophaalt naar eenheden uit een datainterpretatie. Dit is ook de grote kracht van
Profiler. De rauwe gegevens die Profiler normaal bezit zijn echter anders van aard dan de rauwe gegevens van
filterstellingen. Bij boringen en sonderingen worden namelijk de MEETgegevens gebruikt, terwijl het bij de filterstellingen
alleen om de boorgatINRICHTING gaat (dus: welk materiaal hebben we aangebracht). Het lijkt onzin om de gegevens van een
bepaald stuk pijp te gaan interpreteren en in te delen in een eenheid, maar het kan denkbaar zijn dat dit toch gewenst is
(als je bijvoorbeeld zoekt naar alle filters die dikker zijn dan... enz.). Bovendien is het in verband met het Profiler
Mechanisme ook eenvoudiger en consistenter om de gegevens toch maar te interpreteren. Dit gebeurt immers overal en als we de
gegevens interpreteren (al is het 1 op 1), dan kunnen we meteen via het bestaande mechanisme legenda's en zelfs
gebruikerslegenda's toe kennen aan filterstellingen... Ik pleit dan ook VOOR het gebruik van de legenda engine voor
filterstellingen, ookal is dit misschien niet helemaal correct, gezien de achtergrond van de gegevens.....

3. De weergave
Het is het meest logisch om alle buizen van een filterstelling in één kolomweergave component te stoppen. Net als lithologie
en lithostratigrafie hangen de gegevens immers samen. Het is dan ook mogelijk om de instellingen van de verschillende buizen
in de filterstelling tegelijk aan te passen (denk bijvoorbeeld aan het veranderen van legenda. Je hoeft dit dan niet per buis
in te stellen). Het weergave component krijgt ook een scherm waarin de onderliggende gegevens kunnen worden bekeken. Ook is
het eventueel mogelijk om in dit scherm aan te geven welke buizen wel of niet moeten worden weergegeven en in welke volgorde.
Er doet zich bij deze opstelling echter wel een probleem voor. Kolomweergaven hebben namelijk een relatie met slechts 1
kolomdata object. Voor boringen en sonderingen is dit allemaal in orde, omdat daar slechts 1 kolom met gegevens is. In een
filterstelling zijn echter meerdere kolommen mogelijk (zelfs standaard). Er zijn zeker 3 globale mogelijkheden om dit op te
lossen:

3.1: Modelwijziging: een locatie (en dus ook een kolomweergave) kan refereren naar meerdere kolomdata objecten
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
De titel zegt al genoeg. Persoonlijk lijkt mij dit geen goed idee, omdat een dergelijke modelwijziging verregaande gevolgen
heeft voor het mechanisme van Profiler. Alle functionaliteit moet immers weer nagelopen worden om te kijken of het ook
correct werkt met meerdere kolomdata objecten. Bovendien is het logisch gezien ook niet nodig dat meerdere kolomdata objecten
onder één kolomweergave component te hangen, alleen in dit geval wel omdat de kolommen een zekere relatie hebben.

3.2: Modelwijziging: kolomweergaven kunnen een relatie met elkaar hebben
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Logischer is een modelwijziging waarin het mogelijk wordt om verschillende kolommen aan elkaar te koppelen. Buizen in een
filterstelling zijn immers allemaal enkele kolommen die voor het gemak worden gegroepeerd, omdat ze een relatie hebben (ze
horen allemaal bij één boorgat). Ook deze oplossing lijkt mij echter niet ideaal, omdat ook hier vrij veel werk bij komt
kijken. Meer zelfs nog dan bij modelwijziging 3.1, omdat het voor alle mogelijke kolomweergaven mogelijk moet kunnen zijn om
gekoppeld te worden aan andere kolomweergaven. Dit is lastig te realiseren omdat kolomweergaven COM-componenten zijn en ook
allemaal hun eigen specifiek schermen en menu's hebben. Lijkt mij dus niet ideaal. Objectief gezien is het echter wel een
goede oplossing, omdat het de mogelijkheid biedt kolommen te groeperen (wie weet is het ooit nog eens handig)

3.3: Compromis: Intelligenter component
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Een realistischere en niet incorrecte oplossing is om extra intelligentie in te bouwen, waarmee een bepaald component de
gegevens van de verschillende buizen in één kolomdata object kan stoppen en er weer uit kan halen. Zo hoeft het model niet
gewijzigd te worden, en is het toch mogelijk om de filterstellingen te groeperen binnen één kolomweergave component. Deze
aanpak is te verdedigen, omdat het een hoop problemen bespaart en op zich niet fout is, omdat de filterstellingen juist een
uitzondering op de regel zijn (als dit niet het geval is, kan het compromis worden afgeschoten).
De vraag is dan echter in welk component die intelligentie moet worden bijgebouwd. Als eerste zou je kunnen denken aan het
kolomdata object. Dit zou een boolean kunnen krijgen waarmee duidelijk gemaakt kan worden dat dit kolomdata object meerdere
kolommen bevat. Dit zou een logische oplossing zijn als we weten dat het in de toekomst voor kan komen dat meerdere
kolomweergave componenten ook meerdere kolommen zouden kunnen hebben. Is dit echter niet zo, dan zou het onzin zijn om de
intelligentie in het kolomdata object te leggen, aangezien meerdere kolommen een uitzondering zijn.
Is het dus ECHT zo dat meerdere kolommen in één component een uitzondering zijn (wat volgens mij zo is), dan kan de
intelligentie in de kolomweergave component gelegd worden. Die kan dan zelf zien wat de verschillende kolommen zijn....
Op zich is het helemaal niet moeilijk om meerdere kolommen in één kolomdata component te stoppen. Je kijkt immers van boven
naar beneden en van elke laag weet je de boven- en onderdiepte. Zodra je een bovendiepte tegenkomt die hoger ligt dan de
laatste onderdiepte die je bent tegengekomen, weet je dat je in een andere kolom zit...

Ik denk dat het beperkt blijft bij het schrijven van een extra inleesmechanisme en een nieuwe kolomweergave component. Ik zie
hierin ook nog niet veel moeilijkheden verschijnen..... Het enige wat misschien wat lastig is, is het afbeelden van
volgnummers boven de buizen. Die moeten namelijk binnen het weergavecomponent getekend worden. Ook moeten we er nog voor
zorgen dat de filterstelling kolom op de juiste hoogte komt te staan. Hoe zit dat eigenlijk, met de hoogte van de bovenkant?

posted by Davy at 07:50 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 15-02-2001
- D.D. de Kerf
- PC06
---------------------------------

(10:54) Gisteren bijna heel de dag nog besteed aan de Treefile->StaticRecordSet conversie functionaliteit in Extended Setmanager. Verder heb ik de queries in DumpDB toegevoegd en de resultaten geëxporteerd naar een treefile dat moet dienen als (read-only) vervanging voor de programma database in Profiler Lite. Het inleesmechanisme moest ook nog enigszins worden aangepast, zodat in de Lite versie de recordsets niet uit de database, maar uit de static recordsets in SetManager gehaald worden...

Vanochtend heb ik het zaakje gedebugd en ik nu draait het als een tierelier. Na het inlezen heb ik bovendien de static recordsets maar weer verwijderd, want anders was het geheugengebruik nogal fors. Logisch, omdat i.p.v. een database alle gegevens nu rechtstreeks in het geheugen worden geladen. Het geheugengebruik stijgt eerst flink (bij het inlezen van de treefile). Vervolgens wordt alles uit de treefile gekopieerd naar static recordsets, waardoor het geheugengebruik verdubbeld. Dan wordt de treefile weer weggegooid en daalt het geheugengebruik dus weer, totdat alle gegevens in de profiler datastructuur is gezet..... Je ziet nu (als je goed kijkt) 2 hobbels in het geheugengebruik, maar voor de rest is alles in orde. Tijd om aan de rest van Profiler Lite te beginnen....

Het is mij echter nog niet helemaal duidelijk is, is hoe ik de COM-componenten waarmee Profiler te maken krijgt, duidelijk kan maken dat Profiler in Lite-edition draait..... Daarom wacht ik even af tot ik met Edwin heb overlegt over wat er precies wel en niet in de Lite versie moet en hoe we dat gaan aanpakken....
posted by Davy at 02:01 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 15-02-2001
- D.D. de Kerf
- PC06
---------------------------------

Gisteren heb ik de rest van de dag besteed aan het verhuizen van het intranet naar een stabiele server (INTRA01) en het uitbreiden van de 'Window Factory' library die ik aan het maken ben. Dit heeft allemaal te maken met het inbouwen van de functionaliteit voor Profiler Lite. In punt 2 merkte ik namelijk al op dat het mogelijk moest zijn om via DumpDB eenvoudig query results te kunnen exporteren naar tree files. Welnu, daarvoor moest ik dus eerst een goede query-functionaliteit in DumpDB inbouwen en DAARVOOR had ik weer een scherm nodig om queries te kunnen toevoegen, bewerken en verwijderen... Zo'n scherm waar je er in je loopbaan misschien wel 40 van maakt. Daarom kwam het idee om een dergelijk scherm in WindowFactory te integreren, zodat dit de laatste keer zou zijn dat ik zo'n scherm moest maken....

Vandaag ga ik daarom ook beginnen met het integreren van WindowFactory in DumpDB om queries te kunnen 'managen'.

(13:46) Zo, DumpDB is nu, m.b.v. Window Facotry, zodanig uitgebreid dat de gebruiker zelf een aantal queries kan voordefiniëren. DumpDB heeft dan ook bij elke database connectie een nieuwe map met daarin de queries. Bij het afsluiten van DumpDB worden de queries opgeslagen in een TreeFile ( ;-) ), namelijk queries.trf. Bij het opstarten worden ze uiteraard ook weer ingelezen... Verder kunnen de resultaatsets van queries ook worden geëxporteerd naar treefiles, wat betekent dat punt 2 van gisteren nu volledig is afgewerkt. Tijd om punt 1 af te werken (in STF-tijd).

(14:47) In principe zit de functionaliteit van het inlezen van TreeFiles nu in STF. Er was binnen STF reeds de mogelijkheid om zogenaamde 'static queries' aan setmanager toe te kennen. SetManager heeft dan ook een lijst met static recordsets als member. De resultaatsets die uit de treefile worden ingelezen, worden dan ook weggeschreven naar deze lijst van static recordsets.... Eigenlijk is aan SetManager een soort TreeFile parser toegevoegd ;-)
Overigens heb ik alle nieuwe functionaliteit m.b.t. het inlezen van TreeFiles in Extended SetManager gestopt. Zo blijft btaClass_SetManager zich beperken tot de 'essentials' ;-)
posted by Davy at 23:32 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 14-02-2001
- D.D. de Kerf
- PC06
---------------------------------

(10:10) Ik heb vanochtend vroeg de queries bij het opstarten van profiler herschreven. Het resultaat is vrij aardig. Ik heb het idee dat er flink wat performance mee gewonnen is. Sinds de 2 programmadatabases ging het inlezen namelijk een stuk langzamer (logisch, aangezien alle queries op 2 databases moeten worden uitgevoerd), maar na deze fix gaat het ongeveer net zo snel als vroeger op één database..... Ook is het aantal queries bij het inlezen teruggebracht van 48 naar 19!

De volgende stap is het 'inlezen uit treefile' verhaal. Hierbij heb ik sowieso al 3 aandachtspunten:
1) Treefiles moeten kunnen worden ingelezen en omgezet naar staticrecordsets. Deze functionaliteit moet geschreven worden.
2) Je moet ook eenvoudig treefiles kunnen maken vanuit DumpDB. Nu kan dit al voor tabellen, maar je moet natuurlijk ook de resultaten van zelf gedefinieerde queries kunnen exporten. Ik was dit toch al eens van plan om te bouwen en nu lijkt me een goed moment. DumpDB krijgt op de een of andere manier een aparte map met 'user defined queries'. De resultaten kunnen via het bestaande framework worden geëxporteerd.
3) Het inleesmechanisme van Profiler kijkt niet alleen naar de inhoud van de queries, maar ook naar de database ID's. We werken nu immers op 2 databases en dubbele waarden moeten worden gemeid. Daarom heeft elke row in een EmptyRecordset de mogelijkheid om te laten kennen uit welke fysieke database die row gehaald is. StaticRecordsets kunnen dit echter nog niet. Daarom moet ik hier nog een goede oplossing voor zoeken.

Als deze drie aandachtspunten zijn behandeld, kan het mdb-bestand voor de Profiler Lite versie worden verwijderd.... Hopelijk kom ik vandaag al vrij ver. In principe ZOU HET vandaag af kunnen, maar ik beloof niets. ;-)


(11:07) Aandachtspunt 3 is in principe verholpen. Ik heb 'GetDatabaseID' een functie van btaClass_RecordSet gemaakt. Elke btaClass_RecordsetMember heeft nu een databaseID. Met de functie 'SetDatabaseIndex' kunnen alle members op een bepaalde waarde worden gezet. EmptyRecordset zet (dus, verandert) de dataseindex in het begin en bij elke MoveNext actie waarbij naar een andere database wordt geswitched. StaticRecordSet krijgt bij elke BufferQuery aanroep (waarin de inhoud wordt gezet) een databaseIndex mee en slaat deze op in de records. Nu moeten de DBID's ook nog mee geëxporteerd kunnen worden naar het treefile formaat.
posted by Davy at 23:14 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 13-02-2001
- D.D. de Kerf
- PC06
---------------------------------

Ik ben nu al enkele dagen weer flink aan het werk met Profiler en het vordert aardig, moet ik zeggen. Ik heb de volgende dingen gedaan de afgelopen dagen:
- STF 4.1 (zoals die op het moment is) geïntegreerd;
- Functionaliteit 'CloneDB' ingebouwd in STF 4.1, zodat het mogelijk wordt om transparant meerdere databases te gebruiken via één setmanager. Nu is het mogelijk om met één query in één resultaatset gegevens uit meerdere databases (met dezelfde structuur) tegelijk te kunnen halen;
- CloneDB toegepast op ProfilerApp (bij het inlezen van btaClass_Main) en LegendaApp;
- Met behulp van DumpDB de access database gedumpt naar SQL create- en insert scripts en de database aangemaakt in de WEST_V1 onder de gebruiker profiler_dba (pass: profiler_dba).

Vandaag staan op het programma het leegmaken (maar niet helemaal leeg!) van de access database en profiler draaiend krijgen met twee programma databases.

Verder kijk ik alvast eens naar wat TNO informatie over de filterstellingen die over enkele weken ook in Profiler gevisualiseerd moeten kunnen worden.



(17:24): OK, volgens mij is het in orde. CloneDB had nog enkele kinderziekten, maar ik geloof dat het nu vrij aardig werkt, allemaal. Heb tot op zekere hoogte getest, dingen toegevoegd enz. Dankzij DumpDB heb ik ook vrij makkelijk de database kunnen porten naar Oracle. Het enige probleem dat hierbij optrad was het feit dat Oracle geen boolean velden aanvaardt in zijn tabellen en dat enkele tabelnamen te lang waren.

Heb al eens goed nagedacht over Profiler Lite, waarin o.a. de programmadatabase gekilled zou moeten worden. Mijn idee is om dit voor elkaar te krijgen door de queries die bij het inlezen van de database worden gebruikt, met DumpDB te exporteren naar een treefile. Deze treefile zou STF dan moeten kunnen omzetten naar btaClass_StaticRecordset objecten, zodat de rest van de code kan blijven zoals die is. De mogelijkheid om STF treefiles in te kunnen laten lezen, lijkt mij sowieso een goede keus. Dit kunnen we dan later ook nog op andere plekken toepassen....

Zojuist heb ik alvast de queries even bekeken die worden uitgevoerd door CMainFrame bij het opstarten. Hieruit kon ik concluderen dat het niet mogelijk is om in deze vorm de STF-oplossing toe te passen omdat er op sommige plaatsen WHERE-clausules worden meegegeven die ik niet kan voorspellen.... WEL is het mogelijk om de queries zo om te schrijven dat de STF oplossing WEL mogelijk is.... Nu zul je denken: ben je dan niet net zo gemakkelijk af als je gewoon twee versies van het opstarten maakt.... Ik denk het niet. De herstructurering die de queries namelijk nodig hebben spelen ook in hun voordeel qua performance... Ik geef een voorbeeld.

Nu staat er bijvoorbeeld (in pseudocode):
Query = "SELECT * FROM criterium";
while (!Query.IsEOF())
{
ID = Query.criteriumID;
Query2 = "SELECT * FROM criteriumeenheid WHERE criteriumID = " + ID;
while (!Query2.IsEOF())
{
Query2.MoveNext();
}
Query.MoveNext();
}

De aanpassing die ik in gedachten had is als volgt (in pseudocode):
Query = "SELECT * FROM criterium ORDER BY criteriumID ASC";
Query2 = "SELECT * FROM criteriumeenheid ORDER BY criteriumID ASC, eenheidID ASC";
while (!Query.IsEOF())
{
ID = Query.criteriumID;
ID2 = Query2.criteriumID;
// In principe is ID nu gelijk aan ID2, behalve als dit criterium
// geen eenheden heeft
while (ID == ID2)
{
ID2 = Query2.criteriumID;
Query2.MoveNext();
}
Query.MoveNext();
}

Bij de tweede methode worden slechts 2 queries uitgevoerd en doorlopen. Met de eerste methode worden weliswaar kleinere recordsets gecreeerd, maar veel meer queries doorlopen, namelijk één voor het overzicht van criteria en één voor elk criterium apart.

Het eerste wat ik morgen dus ga doen is die queries omschrijven.
posted by Davy at 08:39 [edit]