cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: SQLExec query
Date Sun, 25 Jan 2015 11:59:06 GMT

> On Jan 25, 2015, at 6:41 AM, Ari Maniatis <> wrote:
> Why are you using "execute" instead of performQuery?

(steering this discussion to dev)

Queries like SQLExec will mirror most execution method names from ObjectContext, so let's
focus on ObjectContext API here. Here is a big picture of the relevant API. Some of it exists
already, some is planned for M3.

For selecting queries:

List performQuery(Query)  // current, will be deprecated eventually
List<T> select(Select<T>) // added in M2
T selectOne(Select<T>)    // added in M2 

Non-selecting or "multi-part" queries:

QueryResponse performGenericQuery(Query) // current, will be deprecated eventually
List<QueryResult> execute(Query)         // added in M3
int[] updateBatch(Query)                 // added in M3
int update(Query)                        // added in M3

So general evolution of the new execution methods is to create new verbs to (1) be more precise
about a given operation flavor, (2) to avoid conflict with the established APIs (that will
be eventually deprecated), and (3) to be internally consistent. "execute" instead of "performGenericQuery"
addresses concerns #2 and #3.


> On Jan 25, 2015, at 6:25 AM, Andrus Adamchik <> wrote:
> Starting to experiment with fluent API for non-selecting queries. Since I'd like to avoid
delaying 4.0.M2 release any further, I created a pull request instead of committing it to
> So now executing SQL will look like this:
> int inserted = SQLExec
>     .query("INSERT INTO ARTIST (ARTIST_ID, ARTIST_NAME) VALUES (#bind($id), #bind($name))")
>     .paramsArray(55, "a3")
>     .update(context);
> or like this:
> List<QueryResult> = SQLExec
>     .query("INSERT INTO ARTIST (ARTIST_ID, ARTIST_NAME) VALUES (#bind($id), #bind($name))")
>     .paramsArray(55, "a3")
>     .execute(context);
> The second form ("execute") is more generic. It is not very useful for this simple example.
Still need some actual tests that would execute multiple statements via a single SQLExec.
I know you can do it when calling a stored procedure (which would be a separate query), but
IIRC most drivers will blow if you put multiple SQL statements in a single JDBC PreparedStatement.
> Still, I am showing it here with an eye on eventually refactoring ObjectContext.performGenericQuery(..)
to also return result in a form of List<QueryResult> (instead of current ugly QueryResponse).
> Comments are welcome.
> Andrus

View raw message