[Java]Class library om queries te genereren

[Standeman]

Ik heb zelf altijd een hekel gehad om SQL tussen mijn code op te nemen. Nu zit ik op een project waar alles plain-text in de DAO objecten geprakt zit en dat is niet grappig wanneer je bijv. een tabelnaam wilt veranderen. Je moet dan tig classes en hopen dat je niets vergeten bent. In principe zou ik liever een ORM framework gebruiken, maar dat zit er even nu niet in, dus zit ik gewoon vast aan JDBC.

Nu ben ik al even bezig geweest en heb ik een simpele QueryBuilder objectje gemaakt dat eenvoudige selects kan doen op basis van een SqlMetaData object (welke table en colomn info bevat en ook van een ResultSet een object kan maken). Enfin, grappig hobby dingetje. Ik zit nu ook te kijken hoe ik joins kan toepassen in mijn homebrew "SQL framework".

Aangezien ik niet direct het idee had hoe ik het toevoegen van joins moest aanpakken, ben ik op zoek gegaan naar soortgelijke class libraries. Tot mijn verbazing kon ik er eigenlijk geen vinden. Wel een hoop UI Tootljes, maar daar ben ik dus niet naar op zoek.

Dus mijn vraag, weet iemand een java class library / framework voor het genereren van SQL waar ik in kan spieken?

[Vincenz0]

Het is niet meteen een antwoord op je vraag maar misschien kan het helpen.

Op mijn werk hebben wij een vergelijkbaar probleem, ik praat dan over een softwarepakket met miljoenen lijnen code waarbij SQL overal kris kras door elkaar zat. Als je dus inderdaad een DB wijziging wilde toepassen kon hij op de raarste plekken vast lopen.

We hebben dit opgelost door alle query's in "views" of (meestal) "stored procedures" te zetten. We zijn hier maanden mee bezig geweest om alles te herschrijven, de zelfde query's bij elkaar te zoeken en in 1 procedure te stopen maar het resultaat mag er zijn. Als er nu een DB wijziging is word de procedure of view vanzelf invalid en hoeven we die alleen even aan te passen.

Het ligt er natuurlijk aan of je database "stored procedures" en "views" accepteert, maar eigenlijk hebben alle redelijk grote databases dit wel.

[ Voor 2% gewijzigd door Vincenz0 op 17-04-2009 09:48 . Reden: typo ]

[simon]

Jij zoekt dus een database abstraction layer. Moet wel met google te vinden zijn.

[Standeman]

simon schreef op vrijdag 17 april 2009 @ 09:47:
Jij zoekt dus een database abstraction layer. Moet wel met google te vinden zijn.

Er zijn iig heelveel PHP abstraction layers

[Salandur]

een join binnen hibernate is niets meer dan een associatie van de ene class naar de andere class. dit kan een relatie zijn maar ook subclasses, waarbij elke subclass zijn eigen tabel heeft.
dit moet je dus op de een of andere manier zien te modeleren in jouw eigen frameworkje

[Mr_Light]

In principe zou ik liever een ORM framework gebruiken, maar dat zit er even nu niet in, dus zit ik gewoon vast aan JDBC.

Waarom pricies?

Anyway, uiteindelijk leaked by zo'n tooltje toch wel alle complexiteit door. Het lost volgens mij weinig op en zorgt alleen voor extra dingen die stuk kunnen gaan.

Wat betreft het hernoemen van kolommen en tabellen stop de namen in enums en override toString() - ala single point of definition / DRY

Mocht je het perse willen kan je daar een libary omheen bouwen welke middels type-safety afdwingd dat je die enums/constanten gebruikt.

Dus zou je op zo iets moeten uitkomen:

Java:

        Query query = new Query();
        query
            .select(FIRST_NAME,LAST_NAME)
            .from(Person)
            .where(and(equal(FIRST_NAME,0),equal(FIRST_NAME,1)));
        PreparedStatement statement = query.toPreparedStatement(parameters);

(code is niet af maar mocht je de code willen hebben die er wel al is moet je maar even roepen)

Als je iets slimmers wilt zou ik gewoon een ORM tool pakken.

[Standeman]

Mr_Light schreef op vrijdag 17 april 2009 @ 11:24:
[...]

Waarom pricies?

Als ik Hibernate (JPA) ga inzetten, wil ik gelijk de hele applicatie reworken. De applicatie zelf zit nu vrijwel helemaal relationeel in elkaar (objecten hebben geen relaties met elkaar m.u.v. ID's). Dat zuigt eigenlijk best wel. Helaas is daar nu geen tijd voor (er moet vooral functionaliteit uitgepoept worden).

Anyway, uiteindelijk leaked by zo'n tooltje toch wel alle complexiteit door. Het lost volgens mij weinig op en zorgt alleen voor extra dingen die stuk kunnen gaan.

Daar heb je wel gelijk in . Maar voorlopig is het gewoon nog een hobby projectje. Het belangrijkste vind ik nu nog dat alle metadata slecths 1 maal gedefinieerd is. Dan ben ik al een stuk verder en wordt de applicatie al een stuk stabieler.

Wat betreft het hernoemen van kolommen en tabellen stop de namen in enums en override toString() - ala single point of definition / DRY

Mocht je het perse willen kan je daar een libary omheen bouwen welke middels type-safety afdwingd dat je die enums/constanten gebruikt.

typesafety zou wel leuk zijn, maar ik zie het meer als een extratje. Ik ben al blij wanneer ik de joins er in geknutseld heb.

Dus zou je op zo iets moeten uitkomen:

Java:

        Query query = new Query();
        query
            .select(FIRST_NAME,LAST_NAME)
            .from(Person)
            .where(and(equal(FIRST_NAME,0),equal(FIRST_NAME,1)));
        PreparedStatement statement = query.toPreparedStatement(parameters);

(code is niet af maar mocht je de code willen hebben die er wel al is moet je maar even roepen)

Als je iets slimmers wilt zou ik gewoon een ORM tool pakken.

Ik heb een queryBuilder object en dat ziet er ongeveer zo uit:

Java:

        EmployeeSqlMetaData esmd = new EmployeeSqlMetaData(); //Object met alle tabel info
        SimpleQueryBuilder qb = new SimpleQueryBuilder(esmd);
        qb.createSelectQuery();
        qb.addWhereClause(SubjectSqlMetaData.EMPLOYEE_ID);
        connection.prepareStatement(qb.getQuery())
//Set parameters enzo

Hiermee kan je nu alleen nog maar simpele queires zoals select * from employee where employeeid=3 (ook update, insert en delete) mee maken. Er zit nog een hoop verbetering in natuurlijk.

[YopY]

Zelf heb ik ook zoiets in mekaar gefabriekt, omdat de omgeving waar wij mee werken niet echt goed werkt met externe dependencies (OSGi, en ik wou graag Hibernate gebruiken maar helaas). Een goede Java query builder zou zeker een goede zet zijn - zeker als hij database-onafhankelijk werkt.

Maar aangezien er heel veel verschillende SQL dialecten zijn en ze allemaal iets anders werken, en ook allemaal een iets andere syntax hebben lijkt me het een nogal grote taak om een query abstractie te maken. Misschien zou het leuk zijn als een extra feature in JDBC, dwz dat de databasebouwers zelf een implementatie van een query builder moeten gaan leveren, een aantal basisprincipes in de gaten houdend.

[Standeman]

Voorlopig wil ik alleen de SQL (96?) standaard te "ondersteunen".. (het moet op zijn minst werken met MySQL). Maar ik ben zeker niet van plan om de complete SQL standaard te ondersteunen. Ik bouw wat ik nodig heb (en misschien nog ietsje meer). In DDL heb ik bijv. (nog) geen interesse.

[Sihaya]

Pure interesse: wat is volgens jou het probleem met plain text SQL in je code? Wanneer het parameterized SQL queries zijn, is er op zich toch mee te werken?

Trouwens misschien heb je iets aan quare, een soort LINQ implementatie voor Java. Wellicht is het mogelijk een backend te implementeren dat direct met plain JDBC queries op een database uitvoert.

[Salandur]

Standeman schreef op vrijdag 17 april 2009 @ 11:42:
[...]

Als ik Hibernate (JPA) ga inzetten, wil ik gelijk de hele applicatie reworken. De applicatie zelf zit nu vrijwel helemaal relationeel in elkaar (objecten hebben geen relaties met elkaar m.u.v. ID's). Dat zuigt eigenlijk best wel. Helaas is daar nu geen tijd voor (er moet vooral functionaliteit uitgepoept worden).

Hibernate kan je ook zonder JPA gebruiken, de mappings van objecten naar tabellen kan namelijk prima met de hbm.xml files.

[Verwijderd]

Standeman schreef op vrijdag 17 april 2009 @ 11:42:
Als ik Hibernate (JPA) ga inzetten, wil ik gelijk de hele applicatie reworken. De applicatie zelf zit nu vrijwel helemaal relationeel in elkaar (objecten hebben geen relaties met elkaar m.u.v. ID's). Dat zuigt eigenlijk best wel. Helaas is daar nu geen tijd voor (er moet vooral functionaliteit uitgepoept worden).

Als je ORM dmv een Java standaard wilt regelen zou ik je aanraden om ook is naar JDO te kijken. JPA is meer een subset van JDO dan een superset.