Sounds good. For #3 on SQLTemplate, will these still be able to be defined in the modeler? I like being able to do that, though I only use a single database target for the SQL.
On Fri, Jul 15, 2022 at 2:40 PM Andrus Adamchik <[email protected]> wrote: > Another block of ideas for 5.0. Related to expressions and queries... > > 0. Terse and consistent Expression API. 90% of expressions are done with > Properties now, but the remaining 10% are clunky and inconsistent. I am > thinking the main class (interface) should be called "Exp", combining > static methods from ExpressionFactory and common instance methods from > Expression. The API itself needs to be reworked for fluency and readability > (e.g. no "Exp" suffix in methods like "andExp()", etc.), and should be > aligned with the more modern Property API (e.g. "eq" instead of "matchExp"). > > 1. Merge EJBQLQuery into ObjectSelect. I think we already have the > machinery to implement all features of EJBQLQuery (such as subqueries, > EXISTS, etc.) in ObjectSelect. So let's do that, and then create a parser > (based on the old EJBQL parser, but more Cayenne-centric) to parse > ObjectSelects from Strings. Remove EJBQLQuery, and all the ugliness needed > to support its execution. > > 2. SelectById query is redundant. It can be deprecated and replaced with a > special expression applied to ObjectSelect. With the new Exp API this may > look like this: > > ObjectSelect.query(MyEntity.class).where(Exp.byId(5)); > > On top of that we can probably do something via generated Properties. > > 3. SQLTemplate should be deprecated. SQLExec (and partially - SQLSelect) > replaces it. One feature that SQLTemplate supported is multiple sets of > PreparedStatement parameters ("batches"), that we can potentially port to > SQLExec. > > 4. Replace QueryResponse with QueryResult. Same thing, better API. Keeping > them both is redundant. > > 5. "statementFetchSize" should be fully integrated. Currently it has no > effect on MySQL, without somehow manually setting a few extra Statement > parameters [1] : > > conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, > ResultSet.CONCUR_READ_ONLY); > > Cayenne should take care of it, allowing the users to process large > cursors [2]. > > 6. "timeout(long,TimeUnit)" - should result in setting Statement timeout. > Need to test how well it works on different DBs. > > Andrus > > > [1] > https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-implementation-notes.html > < > https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-implementation-notes.html > > > [2] https://github.com/nhl/link-move/issues/142
