Reason for WIP: Would raise another PR to update existing RowAdapter which will convert models.Row to Result.

I have updated SortedSet to ImmutableList to as records received from gcj's readRows would already be sorted.

@sduskis @igorbernstein2 Please have a look

Is this model adapter only used for read rows? or will it be used for mutateRow, ?checkAndMutateRow, readAndModifyRow, etc?

yes, Our intent is to use this adapter for all operations involving models.Row (In case of FlatRow we would be using an existing read.FlatRowAdapter).

This PR has surfaced an deficiency in google-cloud-java client. Not having the cells ordered by default creates a lot of confusion. For example, ReadModifyWrite returns a row that doesn't use a RowAdapter so it will not be sorted. To avoid guessing I think we should just move the sorting to google-cloud-java.

I put together PR here:
googleapis/google-cloud-java#4421

Thanks for adding this sorting feature in GCJ!!

This would make cbt flow easy for converting Row into hbase.Result without any concerns on sorting.
However, As of now we are wrapping existing native CBT implementation using GCJ's model, So until we be moves 100% to GCJ's adapter(i.e. #1973) we should keep this sorting in ModelRowAdapter.

Please let me know your thought on this.

I don't quite understand what you mean. When will this be called with a Row that doesn't have sorted cells?

This would make cbt flow easy for converting Row into hbase.Result without any concerns on sorting.

I meant by above is, once we move to GCJ's adapter we won't have to sort the cell.

However, As of now we are wrapping existing native CBT implementation using GCJ's model, So until we be moves 100% to GCJ's adapter(i.e. #1973) we should keep this sorting in ModelRowAdapter.

But as of now we would have to keep SortedSet & TreeSet same as exisitng sorting (exsiting cbt RowAdapter) untill we start using GCJ adapters for both data & admin client.

@sduskis @igorbernstein2

I know we had already discussed ModelRowAdapter in this PR, But I have put together another approach in #2061 to make existing RowAdpater, adapt to GCJ's models.Row here.

As I mentioned above, we would have to keep TreeSet in RowAdapter till we start using GCJ's adapter(as of now we are just using its model classes, not the actual client).

Please have a look and let me know of your thoughts.

Would it be ok to keep a FlatRow instead of using model.Row as the output of reads?

I think we should be ok to use FlatRow, as we have its separate adapter i.e. FlatRowAdapter.

here the conversation about the same in #2034.

Could we close this PR?
As we are updating existing RowAdapter to convert models.Row to Result, which previously this PR's ModelRowAdapter meant to do.