Es scheint, dass das Festlegen von search_path zumindest vorerst außerhalb des Bereichs von jOOQ liegt. Theoretisch könnten wir Java-Migrationen in Flyway verwenden und alle Referenzen innerhalb einer Funktion dazu zwingen, explizite Schemas zu haben, aber das klingt ziemlich schmerzhaft. Wir müssen also entweder den Suchpfad manuell festlegen, ihn möglicherweise zu unserer Transaktionsverwaltung hinzufügen oder einen intelligenteren ConnectionProvider schreiben.
Wir haben in unserer Anwendung ein ziemlich strenges Modell mit einer Abfrage pro Transaktion, sodass es nicht wirklich eine Transaktionsverwaltung gibt, zu der die Abfrage "set search_path =..." hinzugefügt werden könnte. Die ConnectionProvider-Lösung scheint unsere beste Option zu sein.
Wir haben bereits eine benutzerdefinierte ConnectionProvider-Implementierung für das Verbindungspooling, daher war es kein allzu großer Aufwand, die Logik (oben am Ende der Frage angegeben) zum Festlegen des Suchpfads hinzuzufügen. Wir könnten es leistungsfähiger machen, indem wir die Verbindung mit etwas dekorieren, das sich daran erinnert, auf was sein aktueller Suchpfad eingestellt ist, und ein "set search_path =...;" voranstellen. an den Anfang jeder Aussage, bevor sie zur Tür hinausgeht, wenn es sein muss. Wir sehen bereits eine Auswirkung auf die Leistung, wenn der search_path bei jeder Anfrage festgelegt wird, daher ist es nur eine Frage der Zeit, bis dies erforderlich wird. Nun, das oder zurück zum Schmerz unserer alten proprietären Datenbankzugriffsschicht.
Zumindest werde ich dies nicht als Antwort akzeptieren, bis ich die Verbindungspooling-/Suchpfadeinstellung ConnectionProvider geschrieben und als Open Source veröffentlicht habe, in der Hoffnung, dass jemand anderes eine bessere Lösung findet, bevor ich dazu komme.
