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 <aadamc...@gmail.com> 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
