Yeah, we should. May need to split the UI for SQLSelect and SQLExec in the
Modeler into 2 separate queries.
> On Jul 18, 2022, at 4:37 PM, John Huss <johnth...@gmail.com> wrote:
>
> 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
