On Tue, Apr 2, 2013 at 3:27 PM, Lukas Eder <[email protected]> wrote:
> > I understand the arguments brought up by Christopher Deckers, which are > mainly: > > 1. The name is too generic to be linked to jOOQ > 2. The name is too generic to be used easily in auto imports, code > navigation, Google searches > > I personally did not agree with the above because of > > 1. The class is in a package, which clearly links it to jOOQ > 2. The class is in a package, which clearly links it to jOOQ > (except for auto imports) > > I don't know if I would make either of these two arguments. Instead I would say its all about "new user" experience. I know when I first took a look at jOOQ that the static import of an "impl" "Factory" was a little strange. I got over it. Its still weird, I just don't care that much. :-) > But I may not suffer from the same pain as you, the users. Also I'm > curious about the potential of finding a better name. > > So please, if you feel either way (pro / contra "Factory"), bring up > your arguments in favour / against the current name. If you're against > it, please also bring up a compelling alternative. By "compelling", I > don't mean things like "Builder", "SQL", "API", but something that > clearly communicates the intent of the "Factory", which are two > things: > > - Being the single point of entry for the jOOQ DSL > - Being the single "factory" for constructing jOOQ QueryParts, > functions, bind values, etc. > > As of jOOQ 3.0, the Factory is no longer: > > - An entity holding "contextual" information about JDBC Connections, > DataSources, Settings, SQLDialect. This information has been moved > outside of the Factory in jOOQ 3.0 and is off-topic for this > brainstorming. > Trying to be helpful here, I propose that things could be broken out into a few modules. 1. Static SQL functions in the Java Sql class - these would include just SQL functions like Sql.max(), Sql.min(), Sql.trim(), Sql.count(), etc. It doesn't include the functions related to the select chain. 2. Static select chain functions should begin in the Java Query class - things including Query.select(), Query.selectFrom(), and items related to RenderMap. From this you could pull the SQL & a variable binding context for helping build Statement or PreparedStatement objects. It would not end with a call to execute() - instead that would be reserved for the contextual Executor class chain. 3. Slightly off topic - but I feel it draws together better... The Executor chain would then have all the context and the different .with() functions. I'm partial to new Executor().with(Connection, Dialect).bind(Query).fetch(); or .execute(), etc, but I can understand if others don't. As is, in jOOQ3 you can do Factory.selectFrom(Tables.MYTABLE).execute(); which of course isn't functional. I understand the Configuration can be attached, but the flow is broken because of that. I guess I view it as if there could be a module for building queries, and a module for executing queries within a connection context. That makes it easier for people to "use the part of jOOQ that works best for your problem". OK I'm done bike shedding this topic - though I enjoy reading it hah. Pete -- 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.
