Announcement Announcement Module
No announcement yet.
BATCH-144 changes Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • BATCH-144 changes

    I am looking for the patches suggested in BATCH-144 in the latest snapshot but can't see to find them (e.g. AbstractDrivingQueryInputSource). Am I looking in the right spot?


  • #2
    BATCH-144 issue shows as IN PROGRESS so some of the changes are not committed yet, but I think the Ibatis input source is there. There are patches attached to the issue itself in JIRA. And there is a base class for the Ibatis guy at DrivingQueryInputSource in the latest snapshots (or SVN). I guess the ase class was renamed, so your might be looking in the wrong place.


    • #3
      BATCH-144 changes

      Thanks for the quick is, however, strange. when I look at batch-144 (create iBatis input and output source), I see it marked as "closed"....



      • #4
        I think that was an administrative error. Looking at Lucas's last comment it seems he meant to mark it as "resolved - fixed" in which case it would not have shown as "in progress".

        To me it looks like the patch was applied and then some changes were made. Was it the IbatisInputSource you were interested in? That looks like it is committed. The output sources are not really framework concerns, since we don's add any value on top of what you could achieve yourself with a few lines of code that are business-oriented.


        • #5
          I saw you post on another unrelated thread:

          I was looking for the abstract class mentioned in the note - "added AbstractDrivingQueryInputSource superclass that encapsulates duplications from IbatisDrivingQueryInputSource and SingleKeyDrivingQueryInputSource."

          I am curious as to how the framework handles iBatis when is doesn't have the capability of iterating over a result set.
          I think the IbatisDrivingQueryInputSource just takes a key generated by the base class and plugs it into an Ibatis query. So there is no iteratio nover a result set per se.


          • #6
            I apologize if there has been any confusion, when I originally wrote the InputSource, I used an Abstract base class for the Jdbc and iBatis versions. However, in subsequent refactorings I created a DrivingQueryInputSource that had a dependency upon a KeyGenerator, which could be implemented with either Jdbc or iBatis.

            DrivingQuery vs Cursor:

            You'll notice in the codebase that there are two types of database InputSources (ItemReaders) cursor, and DrivingQuery. As you can imagine, the cursor InputSources open a cursor up and each call to read() iterates to another row. DrivingQuery input sources require a SQL Query that will return a 'key' to be used to get details. It is a little slower in terms of per record velocity, and requires the initial loading of keys, but in systems where opening a cursor over a large dataset would cause issues, it's a useful option.