On Fri, Sep 28, 2012 at 1:28 PM, Lukas Eder <[email protected]> wrote:
> I must say, I'm a bit confused by this e-mail :-) > Let's go through this e-mail step-by-step > > > The problem with transform the Record is the annoying boilerplate and > loss > > of fluent style. > > Yes, unfortunately, Java 8's lambda expressions aren't available yet. > Note, though, that jOOQ 2.6.0 will also have a RecordMapper, in > addition to the RecordHandler, for a "little" more fluency: > https://github.com/jOOQ/jOOQ/issues/1756 > > > I also just don't like having Record (as an import) all > > over the place. > > It is up to you how far you want to let Record leak into your > application. You can immediately transform it into anything else > before letting it leave a DAO > > Fair enough. > > But it is decoupled, isn't it? How are the two parts entangled? > > Because the base interface (Select) has like 47 methods on that cannot be replaced or implemented. Those methods have to do with fetching. For example changing how ResultQuery does "intoPOJO" requires quite a bit of work (subclassing) all those steps. I guess what I'm saying is that I cannot change how ResultQuery works and its included in the SQL building process. So what I mean is Select<ResultQuery> s = should build me a select that will hand off to ResultQuery; ResultQuery r = s.buildSomeSql().handoff() Now I have ResultQuery object that I can fetch stuff or I can plug my own ResultQuery object that may not even be a ResultQuery. > > This means that the SQL building API would make a lot of assumptions > about how fetched Records would later be mapped onto POJO types. In my > opinion, this would couple fetching with SQL building more closely. > Additionally, I think it is hard to get the property() and > orProperty() "selectors" right, as the ParentBean.class would need to > be introspected in order to generate correct SQL, just like in HQL. In > fact, why not just use HQL (or CriteriaQuery?). > Ignore my example. It was a horrible example which confuses the point I am making. What I would prefer jOOQ did is help me compose or build SQL statements that I can than pass around. My example was trying to show how I build a SQL AST (abstract syntax tree) I then pass that AST off to the parameterized contained fetcher. The fetcher/executor than uses the visitor pattern to turn that SQL into real SQL and then execute. I know that SQL composition is not the intent of the library... It was merely an idea. But the handoff idea I think could be valid where you hand off the predetermined SQL to the next phase (ResultQuery). > Please note that jOOQ is about the "database-first" way of thinking. > Mapping *tables* to beans / POJOs should be a secondary concern, the > SQL query and the tables are the primary concern. If you wish to go > the other way round, you probably shouldn't use jOOQ. Of course, the > Actually thats exactly the way I want to go... I want you to give me some nice valid SQL but I execute and do the POJO mapping myself. > jOOQ way of thinking doesn't exclude mapping tables onto beans, but > only once the tables are fetched. > And yeah I can do the POJO mapping sort of myself but its not elegant, and breaks the fluent chain. I could write a custom Record Handler but how can I elegantly plug that in for all my factories? So while: https://github.com/jOOQ/jOOQ/issues/1756 is nice I still have to pass in the handler all over the place. Hopefully some time next week I can put up my little library so that you can see the SQL AST handoff I'm talking about. > > Cheers > Lukas > Cheers -Adam -- CTO Evocatus, Inc. (evocatus.com) (twitter) @agentgt (cell) 781-883-5182
