> On Jan 25, 2015, at 6:41 AM, Ari Maniatis <notificati...@github.com> 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. Andrus > On Jan 25, 2015, at 6:25 AM, Andrus Adamchik <and...@objectstyle.org> 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 master: > > https://github.com/apache/cayenne/pull/64 > > 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 > > >
