adelapena commented on code in PR #1891:
URL: https://github.com/apache/cassandra/pull/1891#discussion_r1120586043
##########
src/java/org/apache/cassandra/db/rows/Cell.java:
##########
@@ -59,14 +69,24 @@
public interface Factory<V>
{
- Cell<V> create(ColumnMetadata column, long timestamp, int ttl, int
localDeletionTime, V value, CellPath path);
+ Cell<V> create(ColumnMetadata column, long timestamp, int ttl, long
localDeletionTime, V value, CellPath path);
}
protected Cell(ColumnMetadata column)
{
super(column);
}
+ public static int deletionTimeLongToGuavaUint(long deletionTime)
+ {
+ return deletionTime == NO_DELETION_TIME ? NO_DELETION_TIME_GUAVA_UINT
: UnsignedInts.checkedCast(deletionTime);
Review Comment:
Directly using `UnsignedInts` instead of instantiating `UnsignedInteger` is
nice. The `UnsignedInts` class is marked as beta and it shows a distracting
warning on the four classes where it's used. The warning seems quite ignorable
since the two only methods we use look quite simple and safe.
Perhaps we could avoid the warning by wrapping those two methods into our
own utility class. That should hide the warning and isolate the Guava
dependency. It would also make easy to change the implementation in the future,
if we wanted to do so. That wrapping would look like:
```java
package org.apache.cassandra.utils;
import com.google.common.primitives.UnsignedInts;
public class UnsignedIntegers
{
public static int fromLong(long value)
{
return UnsignedInts.checkedCast(value);
}
public static long toLong(int value) {
return UnsignedInts.toLong(value);
}
}
```
Since we would be encapsulating the Guava dependency into the utility class,
we could rename some vars to make them independent of the implementation. For
example, `deletionTimeGuavaUint` could be named just `deletionTimeUint`, or
perhaps `deletionTimeUnsignedInteger`.
Wdyt?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
