Hello Kervin, Alot of these libraries, including JPA need to generate beans before you can use the query builder. QueryDSL is one example. I haven't used JOOQ, but I have seen their examples, and it looks a lot like what I thinking of. I am unable to find the licensing of JOOQ, and if it's ASL compatible or not.
Generating dynamic SQL, based on the parameters, rather than using String concatenation, keeps you free to use the format you want to get the results. For example, if we need to get Beans from the resultSet, we can use DBUtils to map the resultset into beans. As you said, these libraries solve a bigger problem, but they come with cost: You need to generate classes before you can use the query builder. On Wed, Jul 1, 2015 at 8:18 PM, Kervin Pierre <ker...@sludev.com> wrote: > Left out... > > * https://github.com/JSQLParser/JSqlParser > * http://querydsl.com > > JSqlParser does a really good job of handling dialects if I remember > correctly. > > QueryDSL also "does the mapping part" as you put it. It gives you a > type-safe query language across Java Collections, JPA Datasources and > others. Almost like .Net's LINQ. > > A third "Java EE Criteria API" is also worth a mention because I believe > it's Java's official entry into this group. > http://docs.oracle.com/javaee/7/api/javax/persistence/criteria/CriteriaQuery.html > > The solutions like QueryDSL, JPA Criteria Query, and JOOQ solve a much > bigger problem. Type-safe Java queries in a data-store agnostic manner. > I.e. no dialects to worry about. > > So my initial thinking is that with so many great solutions out there, > why another library that generates SQL strings? > > Best regards, > Kervin > > On Wed, 2015-07-01 at 08:21 -0700, Adrian Crum wrote: >> You can make the builder support generic SQL 2003, and provide a way to >> extend the builder with vendor-specific grammar. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 6/30/2015 11:10 PM, Benedikt Ritter wrote: >> > Hello Mansour, >> > >> > 2015-06-30 23:57 GMT+02:00 Mansour Al Akeel <mansour.alak...@gmail.com>: >> > >> >> I am not sure if this is the right place to suggest this. Please let >> >> me know, before filling a Jira Ticket. >> >> I believe DbUtils has place for additional component: >> >> >> >> - A fluent API to generate SQL string: >> >> >> >> Developers find it difficult to concatenate strings to build a query. >> >> A fluent API makes it relatively easier, and keeps the query vendor >> >> independent. >> >> Some of the examples: >> >> * http://iciql.com/ >> >> * http://jodd.org/doc/db/sqlgenerator.html >> >> * http://jdbi.org/ >> >> * Jooq >> >> * https://mybatis.github.io/mybatis-3/statement-builders.html >> >> >> >> I am not talking about the mapping part. I am only suggesting >> >> generating the SQL string builder functionality. Something similar to >> >> MyBatis: >> >> >> >> String sql = new SQL() >> >> .INSERT_INTO("PERSON") >> >> .VALUES("ID, FIRST_NAME", "${id}, ${firstName}") >> >> .VALUES("LAST_NAME", "${lastName}") >> >> .toString(); >> >> >> >> I am wondering how much effort this can be, and most important if >> >> thers's interest in the community to create a separate independent >> >> component just for Sql String generation. MyBatis is under ASL 2.0 >> >> license. >> >> >> >> Anyone else think there's a place in DBUtils for this functionaity ? >> >> >> > >> > That's kind of a domain specific StringBuilder for SQL, right? >> > How would you handle different data base dialects? >> > >> > Benedikt >> > >> > >> >> >> >> Thank you. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
