2013/6/25 Durchholz, Joachim <[email protected]>
> > Let's see how this goes. A first attempt of implementing
> > this failed as I have a choice between:
> >
> > - Letting the API explode completely (including sql()
> > methods before/after AND, OR, IN, NOT, CASE, WHEN, THEN,
> > etc. etc.
> > - Offering only few sql() methods e.g. before or after
> > the SELECT statement keywords, in case of which the
> > usefulness of this feature is dubious...
>
> Can't sql() be added to the superclass of all these SQL-generating
> classes? You'd need to play some tricks with generics to make that
> type-safe, but the technique for that is well-established nowadays (I've
> been playing with this enough to use it routinely, so I'm ready to answer
> questions on that).
> Its semantics would be to append the given string to the generated SQL. No
> guarantees about syntactical validity.
>
> Plays havoc with any formatting that the SQL generators might attempt.
> Also, runs into some trouble whenever SQL generation looks at multiple AST
> nodes. (Does it?)
Yes, it would certainly be possible to add a sql() method to a top-level
type, e.g. QueryPart. But the huge drawback of this is that the whole
QueryPart type tree would need to be generified to allow for:
interface QueryPart<Q extends QueryPart> {
Q sql(String sql);
}
Q is necessary to allow for fluent injection of SQL. We'd probably have to
check whether appending or prepending is more useful (or both?). In the
context of a SELECT statement, it could only be "appending". But the slim
added value clearly doesn't pull the weight of the new generic type
parameter. Think about Field:
interface Field<T, Q extends QueryPart> extend QueryPart<Q> {
}
interface TableField<R extends Record, T, Q extends QueryPart> extends
Field<T, Q> {
}
That would be a very "unfriendly" addition for the end-user :-)
>
> > jOOQ already supports a .hint() method, mainly
> > aimed at Oracle users who want to inject query hints:
> >
> > select(a, b).hint("/*+ALL_ROWS*/").from(t)
> >
> > You can use this for other purposes than hints of course.
>
> Ah yes, right, thanks for the reminder.
>
> >> Also, I'm generating views. These are used by third
> >> parties, and I've been making a point of documenting
> >> them to people can see what the view does.
> >> It would be cool if I could do that via Jooq-generated
> >> views, too.
> >
> > What do you consider a "jOOQ-generated view"?
>
> I'm currently generating some overly complicated but regular views from
> Java. That keeps the Java and Oracle side of things in sync, the software
> simply has a maintenance mode where it generates the view definitions,
> ready to be pasted into an SQL command line.
> Doing the SQL generation from Jooq would probably simplify the code.
Should be simple:
// Construct your statement:
Select<?> select = //...
// Render it with inlined bind values:
String sql = DSL
.using((Connection) null, dialect, new Settings()
.withStatementType(STATIC_STATEMENT)
.withRenderFormatted(true) // possibly?
).render(select);
String view = "CREATE OR REPLACE VIEW my_view AS " + sql;
>
> > As with any type of plain SQL, you're on your own.
> > You'll risk to run into syntax errors and SQL injection.
>
> Heh. Fortunately, that type of SQL generation does not process external
> input, just hardcoded definitions.
>
> --
> You received this message because you are subscribed to the Google Groups
> "jOOQ User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
