[
https://issues.apache.org/jira/browse/OOZIE-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694418#comment-14694418
]
Jadiel de Armas commented on OOZIE-2095:
----------------------------------------
I have explored the source code. The majority of the JPAExecutor classes need
to be ported to QueryExecutor. I see two strategies:
1. I could convert each JPAExecutor class into a corresponding QueryExecutor
class.
2. I could add the functionality of the JPAExecutor classes that deal with
UPDATE and SELECT queries to the already existing QueryExecutor classes. But
the SELECT queries that return counts, or the SELECT queries that return some
other primitive datatypes (mainly String because of the job ids) or the DELETE
queries that return Void, will have to go into their own QueryExecutor class.
3. I could add three abstract methods (one for the SELECT count queries,
another for the SELECT String queries and even another for the DELETE queries)
into the QueryExecutor class, and by doing this I could add the majority of the
functionality of the JPAExecutor classes into already existing QueryExecutor
classes.
Which route would be preferable?
> Convert JPAExecutor classes to QueryExecutor
> --------------------------------------------
>
> Key: OOZIE-2095
> URL: https://issues.apache.org/jira/browse/OOZIE-2095
> Project: Oozie
> Issue Type: Sub-task
> Reporter: Rohini Palaniswamy
> Assignee: Jadiel de Armas
> Labels: newbie
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Need to convert JPAExecutor classes to QueryExecutor. JPAExecutor classes
> are inefficient
> - as a class is instantiated every time to execute a query
> - Uses transaction commits even for reads.
> Some might be difficult to get rid of as we do custom sql construction, but
> most can be converted. For eg: CoordJobsGetPendingJPAExecutor which is only
> called with limit -1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
