Skip to content

JAVA-1157: Allow asynchronous paging of Mapper Result#683

Merged
olim7t merged 1 commit into
3.0from
java1157
Jul 15, 2016
Merged

JAVA-1157: Allow asynchronous paging of Mapper Result#683
olim7t merged 1 commit into
3.0from
java1157

Conversation

@adutra
Copy link
Copy Markdown
Contributor

@adutra adutra commented May 25, 2016

This commit also extracts a common super-interface for both ResultSet and Result, as suggested by the ticket reporter. Clirr plugin was happy with that so I went ahead and implemented the idea.

* results as soon as there is less than 100 rows readily available in this
* result set, you can do:
* <pre>
* ResultSet rs = session.execute(...);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The javadocs still mention ResultSet in some places but I guess it's ok since ResultSet is the only child interface of this one in this module.

@adutra adutra added this to the 3.1.0 milestone Jun 1, 2016
@adutra
Copy link
Copy Markdown
Contributor Author

adutra commented Jun 20, 2016

Squashed and rebased on top of current 3.0. Note that I also renamed Fetchableto PagingIterable.

}

@Override
public boolean equals(Object other) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor remark: strictly speaking you don't need to implement equals and hashCode here, since you're accumulating the ids below.

@adutra
Copy link
Copy Markdown
Contributor Author

adutra commented Jul 7, 2016

Rebased and addressed feedback. Does everyone agree that getExecutionInfo() should stay in PagingIterable?


// redeclared only to make clirr happy
@Override
Row one();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is going into 3.1.0, does it matter that clirr isn't compliant for this particular case?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean, you would prefer that I add the exception to clirr-ignores.xml? the exact error is

7002: com.datastax.driver.core.ResultSet: Method 'public com.datastax.driver.core.Row one()' has been removed

@tolbertam
Copy link
Copy Markdown
Contributor

Rebased and addressed feedback. Does everyone agree that getExecutionInfo() should stay in PagingIterable?

Sounds good to me, I like that you don't really lose anything mapping from ResultSet -> Result now, everything is still accessible other than getColumnDefinitions (doesn't seem relevant when using mapped entities) and wasApplied (only applies to updates/deletes so doesn't seem relevant for mapping).


@BeforeMethod(groups = "short")
public void cleanup() {
session().execute("TRUNCATE users");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I worry that truncate can be somewhat/slow unreliable, but it should not remotely be a problem with a smaller set of data, so not worried in this case.

This commit also extracts a common super-interface for both
ResultSet and Result, called PagingIterable.
@olim7t olim7t changed the title JAVA-1157: Mapper should allow asynchronous Result paging. JAVA-1157: Allow asynchronous paging of Mapper Result Jul 15, 2016
@olim7t olim7t merged commit 8a8c3ae into 3.0 Jul 15, 2016
@olim7t olim7t deleted the java1157 branch July 15, 2016 17:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants