Also die Frage ist wirklich, was Du im Detail benötigst bzw. was Dir bei JPA / Hibernate fehlt.
a) Ggf. gibt es ja bereits andere Bibliotheken, die Dir sowas bieten?
b) Evtl. kann man das vorhandene Nutzen und ergänzen?
Jetzt kommen paar Möglichkeiten, aber nur die reine Erwähnung heisst nicht, dass es (für Dich) Sinn macht. Die Aussagen von
@Marinek in #38 solltest Du gut lesen und bedenken!
Wenn man neue Konstrukte entwickeln möchte, dann muss man sich natürlich an die Java Syntax halten. Und da kann man sich dann überlegen, was man bauen möchte. Schon bei User.objects.... wird es ggf. schwierig. Das könnte man ggf. bauen über eine Entity Klasse, von der alle erben müssten um dann kannst Du sehr viel selbst bauen.
filter könnte z.B. genau so aufgebaut werden, wie bei Streams, die da halt ein Predicate<? super T> als Parameter nehmen. Dann wäre es halt eher etwas wie filter( u -> u.status_id_gt = 1).
==> Aber das status_id_gt sieht nach einem Column aus und nicht nach einem Feld. statusIdGt oder so wäre ja vermutlich dann das Feld bzw. wenn das eine id zu einer anderen Entity/Tabelle ist, dann wäre es direkt eine Referenz darauf.
==> Als Entwickler will man im Java Code doch auf der Java Ebene entwickeln und nicht auf der Datenbankebene. Das wird daher auch bei der Angabe von Queries berücksichtigt. Die Möglichkeit von SQL (native) Queries ist natürlich auch gegeben, aber da wäre ich vorsichtig mit der Nutzung. Also Wenn ich ein Feld habe mit @Column(name = ...) und da dann etwas ändere, dann breche ich den Code an anderer Stelle, der als native Query die Abfrage macht. Nutze ich den Feldnamen, dann habe ich deutlich mehr Chancen auf Refactoring Unterstützung und Compile-Zeit.
Wenn Du da eigene Dinge bauen willst, dann geht das natürlich auch. ChatGPT erstellt Dir gerne Code um Entities auszuwerten. Das kann man klein anfangen mit @Column Einträgen. Dann kann man dein @Embedded mit nutzen und das dann nach und nach immer weiter erweitern.
(Ich selbst habe das schon einmal gemacht, weil ich halt JPA Entities vorliegen hatte und nutzen wollte. Nur eben war das Ziel, dass ich BULK INSERT Skripte generieren musste und das Zielsystem unter aktiver Entwicklung ist und ständig geändert wird. Und die Änderungen wollte ich zur Compile-Zeit haben und nicht erst bei Integration-Tests. Also wurden die Entities ausgewertet und dann habe ich z.B. eine Klasse InsertStatement geschrieben, der ich dann halt Feldnamen mit Werten gegeben habe)
Das eigene Lesen kann man sich dann auch überlegen. Da wäre dann z.B. bei filter die andere Idee, dass man es als String übergibt. Also filter("status_id_gt = 1"). Das kann man dann 1:1 nehmen und in eine WHERE Bedingung setzen. Ggf. mit einem Parser, der das etwas prüft.
Ich hatte den Code zum Lesen der Entitäten selbst geschrieben - aber das kann man natürlich auch generieren. Das kann dynamisch (einmalig) erfolgen so dass man da nicht langsame Reflection verwenden müsste. Das ist also auch erst einmal kein Thema. Das wird aber schnell deutlich komplexer, sobald man halt referenzierte Entitäten berücksichtigen möchte und so ...
Also ganz klar: Ja, sowas kann man sich bauen. Das ist von der Komplexität nicht einmal so groß, so man sich bei der Funktionalität stark/etwas einschränken kann. Als Spielerei: Kein Thema. Wie gesagt: Spiel mal mit ChatGPT herum!
Die Idee, Datenbank-Schematas automatisch anzupassen halte ich für sehr problematisch. Du musst halt immer schauen, was mit den Daten passieren soll. Einfache Operationen wie ein Delete oder Add sind ok. Typanpassungen sind aber schon problematisch, weil da Datenverlust entstehen kann. Renames muss man erst einmal als solche erkennen ...
Aber davon unabhängig: Die Datenbank lässt sich über die JDBC Metadaten sehr gut auslesen und auswerten. Um dann halt notwendige Abweichungen zu erkennen. Hier kann eine Idee ja auch sein, dass man nur Change Skripts erzeugt, die dann abgelegt werden. Man gibt dann dem Entwickler die Möglichkeit, diese anzupassen. Und dann würde man die Change-Skripte nur noch automatisiert anwenden. (Aber selbst diese Anwendung von Change-Skripten kann schon eine komplexere Sache werden. Viele Datenbanken haben Möglichkeiten wie Snapshots - das könnte sinnvoll sein. Und auch die Möglichkeit, alles in einer Transaktion oder in vielen Transaktionen zu machen. (Was will man zurück rollen? Alles? Nur das letzte Schema Update, das fehlgeschlagen ist? .... Error Reporting und Auswertungen ist auch ein wichtiges Thema wenn es um produktive, wichtige Daten geht...