Will re-enable it when attribute_groups() are implemented. Just to illustrate what they would return when implemented.

Does == on WideColumns make sense? There is no documented canonical ordering, so the same set of column->value pairs could compare as !=

Columns are always sorted (by name) before added. Not sure if I understand your concern here. Could you provide a quick example?

The data structure is fully defined in wide_columns.h. It is therefore reusable. This (reusable / general) comparison operator assumes an invariant on the data that the class itself does not describe. That mismatch (or omission) is asking for mismatch in expectations (potential bug).

Should this invariant always be true of WideColumns? I don't know, but that should be clear to users and developers.

an invariant on the data that the class itself does not describe

column names and values are always compared bytewise and it's commented in the class, but I think we can do better documentation.

.. that should be clear to users and developers.

Are you worried that it is not clear enough for users and developers to know that WideColumns are always sorted by column names (by bytewise comparison) and both name and value of all columns should match for two WideColumns to be considered equal?

an invariant on the data that the class itself does not describe

column names and values are always compared bytewise and it's commented in the class, but I think we can do better documentation.

Which class? The only reference I see to something like "compared bytewise" is on operator== for WideColumn, which is outside the class. There is no reference to sorting or ordering.

Are you worried that it is not clear enough for users and developers to know that WideColumns are always sorted by column names

I don't see any documentation (APIs in db.h, wide_columns.h or wiki) indicating that sortedness is expected or provided, or whether perhaps the user ordering provided in PutEntity is preserved. I don't even see clear documentation of whether PutEntity completely overwrites a previous PutEntity on the same key or only on a column-by-column basis.

Nor exactly what Delete() does after PutEntity, just "works the same way as for regular key-values." So does it delete only the default column (since you can't specify a column)?

CC @ltamasi

and both name and value of all columns should match for two WideColumns to be considered equal?

The presumption for operator== in C++ is structural equality. The question is what relationship that has to semantic equality, which can be different in various contexts.

I don't see any documentation (APIs in db.h, wide_columns.h or wiki) indicating that sortedness is expected or provided, or whether perhaps the user ordering provided in PutEntity is preserved. I don't even see clear documentation of whether PutEntity completely overwrites a previous PutEntity on the same key or only on a column-by-column basis.

Nor exactly what Delete() does after PutEntity, just "works the same way as for regular key-values." So does it delete only the default column (since you can't specify a column)?

CC @ltamasi

These points are mostly covered by the API comments at https://github.com/facebook/rocksdb/blob/main/include/rocksdb/db.h#L430-L459 , which, similarly to those of Put, use the concept of database entries associated with keys. After a PutEntity, the key is associated with that entity, regardless of any previous value (whether it's a plain KV, an existing entity, or nothing at all); after a Delete, the key is not associated with any database entry, again regardless of any previous value. There is no expectation that the input WideColumns structure is sorted, although it does get sorted by RocksDB, and thus anything read back from RocksDB will be sorted. We can extend the comments to clarify this point.

@jaykorean Sorry about the delay! Will review the PR shortly.

@ltamasi If I was expecting PutEntity to do partial update, I might assume it's sloppy language, overly copying from Put(), even if it's technically correct and consistent. "will be overwritten" doesn't always mean entirely overwritten.

I think part of the confusion is singular "entry" and "entity" when dealing with plural things. Even if the description of Delete() is technically correct, it's not clear that it can deal with plurals like wide columns, especially since there's no DeleteEntity (like PutEntity / GetEntity). A reasonable user would doubt whether it handles new functionality even if its un-updated description technically implies it does.