Protokoll 2013-09-05 Review Philip Haußmann

Aus SDQ-Wiki

Teilnehmer

  • Christian Stier
  • Philip Haußmann
  • Misha Strittmatter
  • Christoph Föhrdes
  • Jörg Henß
  • Philipp Merkle

Protokoll

Allgemein

  • Misha: Methodeninterne Code-Blöcke kommentieren (falls nicht ohnehin Extraktion einer privaten Methode)
  • Misha: QueryTemplateType vs. Template? Name kommt aus OLTPBenchmark

QueryGenerator

  • Christian: fetchTableSample, Rückgabetyp ist ungünstig, besser in Objekt kapseln
  • Jörg: Konfigurationsparameter je Klasse kapseln in spezifischem Konfigurationsobjekt? -> Eher nicht
  • Jörg: main-Methode: shutdown "fällt vom Himmel", besser ein cleanup() aufrufen, welches dann shutdown durchführt

QueryCollectionFileIO

  • Misha: es befinden sich in File Queries + Metriken; anfangs verwirrend (Philipp: am besten Eingabedatei nicht überschreiben, sondern à la "Speichern unter..." ablegen)

DBRequestorRunnable

  • Christian: run-Methode kommentieren

XSD-Schema

  • performanceMetrics sind MSSQL-spezifisch, sinnvoll wäre gemeinsamer Obertyp; Stichwort xsd-Extensions?

Configuration.java

  • Jörg: neue Methden parseInt(), parseDouble() etc.
  • instance wird nie gesetzt -> wird jedes Mal neu geladen
  • Philipp: statt instance besser einen static initializer verwenden? dann aber Speicherort der Config zur Compile-Zeit gefixt, es sei denn man liest den Speicherort wiederum aus einer Config aus

SamplingQueryGenerator.java

  • Christian: createSamplingQuery, warum keine PreparedStatements statt "?" von Hand zu ersetzen?
    • Jörg: Falls nein, dann zumindest "\\?" als Konstante deklarieren
  • Christian: close-Methode taucht in mehreren Methoden auf -> extrahieren in Utility-Klasse?
    • Außerdem: ResultSet wird automatisch geschlossen beim Schließen eines Statements (siehe Javadoc)

QueryInstanceFactory

  • Jörg: StringBuilder verwenden

UpdateFactory

  • Jörg: Seed für Random Generator vorsehen? -> Nein, da an anderer Stelle (SQL-Statement) Zufall hereinkommt, der nicht über Seed kontrollierbar
  • Jörg: " " ist Magic Value, besser Konstante draus machen

Profiler

  • Christian, Christoph: strategy besser im Konstruktor initialisieren

IsolatedQueryProfilingStrategy

  • Christoph: vermisse Collection von Strategien, Strategien sind hart-gecoded, dadurch momentan feste Bindung an MSSQL
  • Jörg: for-Schleife in private-method extrahieren
  • Christoph: Runnable eigentlich in Verbindung mit Threads verwendet; run() sollte nicht direkt aufgerufen werden, oder Interface nicht verwenden

DBRequestorRunnable

  • Christoph: queryTemplate in Konstruktur verschieben, da die Klasse nichts sinnvolles tut ohne das Template
  • Christoph: dmvProfilingDataSource von außen konfigurierbar machen, sont feste Abhängigkeit zu MSSQL

ProfilerDataSource

  • Jörg: SQL-Statements als PreparedStatement?

DBConnectionPool

  • Christian: READ_UNCOMMITTED sollte von außen vom Aufruf ersichtlich sein

TableStatisticsCalculator

  • Jörg: sehr ähnliche Methoden; Wiedervwendung betreiben?
Abgerufen von „https://sdq.kastel.kit.edu/mediawiki-sdq-extern/index.php?title=Protokoll_2013-09-05_Review_Philip_Haußmann&oldid=20305“