Issue Details (XML | Word | Printable)

Key: BATCH-167
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Lucas Ward
Reporter: Lucas Ward
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Spring Batch

Sql Input Source package names should be refactored.

Created: 15/Oct/07 12:57 AM   Updated: 01/Nov/07 10:24 AM
Component/s: Infrastructure
Affects Version/s: 1.0-m2
Fix Version/s: 1.0-m3
Security Level: Public (Public Issues)

Time Tracking:
Not Specified


 Description  « Hide
The sql io sources package names should be refactored. At a minimum, using sql, instead of jdbc, is inconsistent with the rest of the spring framework. So, SqlCursorInputSource should be JdbcCursorInputSource. Also, now that orm solutions have been added, database inputs are spread across different packages: io.support, io.sql, io.orm.hibernate, and io.orm.ibatis. I think it might make more sense to put them under one 'umbrella', separated by cursor and driving query.

 All   Comments   Work Log   Change History   FishEye   Builds      Sort Order: Ascending order - Click to sort in descending order
Dave Syer added a comment - 15/Oct/07 01:32 AM
I agree on the Sql->Jdbc renaming. Not so sure about the packaging - do we really want another level of packages? In fact maybe the "orm" package level could be removed as well? The HibernateInputSource also needs a lot more documentation. Is anyone using it on a project?

Stijn Maller added a comment - 15/Oct/07 03:24 AM
We are using a slightly altered version of it at this moment. (With a normal Hibernate Session instead of StatelessSession)

Lucas Ward added a comment - 18/Oct/07 11:14 PM
Dave,

I wasn't thinking that cursor should just be inserted in front of io.sql, but rather all of the cursor based input sources could be grouped together and all of the Driving Query based as well. For example:

io.database.cursor.JdbcCursorInputSource
io.database.cursor.HibernateInputSource
io.database.driving.SingleKeyDrivingQueryInputSource
io.database.driving.IbatisInputSource

It just seems to me that the distinction of input type doesn't really need to be made at the package level, since the input source is already named appropriately. However, it seems more important to distinguish between how the data is being read in. I would rather the focus be that there are two types of database input sources: drivingQuery and cursor, rather than we support input via jdbc, hibernate, and iBatis, which might also have subdivisions. This would also mean that the AbstractDrivingQueryInputSource could live in a more logical place, since 4 input sources now ultimately extends it. (two ibatis, two sql).

Dave Syer added a comment - 19/Oct/07 12:00 PM
That makes sense. With the interfaces in the parent package?

Lucas Ward added a comment - 19/Oct/07 12:23 PM
There aren't really any interfaces, since all jdbc input sources implement InputSource, which is in batch.io. The only one I can think of is the RestartDataConverter (soon to be a type converter) but it's only currently being used by the driving data input sources. Although, I guess it could be used for cursor input, if the query was to be modified, but there would also need to be a modification to know which column(s) to store.

Dave Syer added a comment - 20/Oct/07 04:07 AM
I just don't like having empty parent packages. Could we just leave it out?

Lucas Ward added a comment - 25/Oct/07 09:56 AM
We could leave it out, and have something like io.driving and io.cursor, as long as you don't think it would be confusing. I guess all the classes in them would make it clear as well, since there would be something like io.cursor.JdbcCursorInputSource.

Lucas Ward added a comment - 01/Nov/07 10:24 AM
The io.sql package has been removed (except in test, where the abstract test class remains) and has been divided into io.cursor and io.driving.