Rethink design of persistence.relational.jdbc.models.Converter
- Dominant language
- Java
- Stars
- 2.1k
- Forks
- 522
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 137
Description
The `Converter` interface is a bit strange indeed. The method above is a pure converter utility, but this one looks like it's meant to convert the object's _internal state_ to some external representation.
This hints at the idea that this interface should be split in two. In `ResultSetIterator` for instance, we only need the `fromResultSet` method.
_Originally posted by @adutra in https://github.com/apache/polaris/pull/2465#discussion_r2315955845_
Contributor guide
Research direction
Start by reading the persistence.relational.jdbc.models.Converter interface and its use in ResultSetIterator. Determine how the conversion methods represent internal state versus pure conversion, then define the two-interface split and update affected usages. Done means ResultSetIterator depends only on the fromResultSet behavior and the existing conversion responsibilities remain covered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- database
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100