gissuebot commented 10 years ago

Original issue created by mar...@alum.mit.edu on 2012-02-17 at 05:19 PM

There are Multisets and Multimaps. Why not Multitables?

gissuebot commented 10 years ago

Original comment posted by wasserman.louis on 2012-02-17 at 05:27 PM

Because there's not enough demand for them. Multimaps have decent demand and moderate complexity; Tables have some demand and slightly greater complexity, but I think the cost/benefit ratio drops off pretty quickly after that point.

Do you have a use case?

Labels: Type-Enhancement, Package-Collect

gissuebot commented 10 years ago

Original comment posted by mar...@alum.mit.edu on 2012-02-17 at 05:38 PM

My just-encountered use case: Searching a set of objects that each have three fields for instances that share the first two fields but not the last. Of course there are many ways of solving this problem (and I just solved it using a regular table). But in the analogous one- and two-field cases I use a Multiset and Multimap, respectively.

I would think that, for conceptual consistency, one would want a Multitable in the API. And, personally, often use Multisets and Multimaps as a builder object to construct sets or maps that satisfy certain properties. The same would be extremely helpful for Tables.

gissuebot commented 10 years ago

Original comment posted by wasserman.louis on 2012-02-17 at 06:38 PM

"Conceptual consistency" is not nearly as relevant to us as the metric of "utility times ubiquity." We can't put in the kind of investment that Multitable would require for the sake of a comparatively tiny number of users. For the same reason, we don't include a "three-keyed map," either.

That said, markaf, I can think of another solution for your specific case: use a normal Multimap, but combine the first two fields into a composite key. It doesn't sound like you need to view the rows or the columns of that table, you just want to look up on multiple keys at once.

gissuebot commented 10 years ago

Original comment posted by wasserman.louis on 2012-02-20 at 05:09 PM

Additionally, the composite-key approach generalizes to arbitrary numbers of fields, in contrast to your proposed Multitable interface, which only get you one extra field.

gissuebot commented 10 years ago

Original comment posted by mar...@alum.mit.edu on 2012-02-20 at 10:42 PM

4 is a reasonable answer.

gissuebot commented 10 years ago

Original comment posted by wasserman.louis on 2012-03-01 at 07:52 PM

I'm marking this as Acknowledged for the moment, unless we find another compelling use case.

Status: Acknowledged

gissuebot commented 10 years ago

Original comment posted by kevinb@google.com on 2012-05-30 at 07:43 PM

(No comment entered for this change.)

Labels: -Type-Enhancement, Type-Addition

gissuebot commented 10 years ago

Original comment posted by kevinb@google.com on 2012-06-22 at 06:16 PM

(No comment entered for this change.)

Status: Research

gissuebot commented 10 years ago

Original comment posted by letallecy on 2013-01-28 at 09:50 PM

Hi Louis, one use case I have is the following:

I would like to store financial instruments tick data in a Table<DateTime, String, Object> where the row is the timestamp, the column is the field retrieved (bid, ask, last, size etc.) and the Object is the value.

However, multiple ticks can occur within the same millisecond (and some exchanges report the ticks with a precision of 1 second, which increases the likelihood of having more than one tick per "cell").

For that specific use case, I would love to have a MultiTable where table.row() and table.column() return MultiMaps instead of Maps.

assylias

gissuebot commented 10 years ago

Original comment posted by lowasser@google.com on 2013-01-28 at 10:01 PM

Do the previously mentioned workarounds not work for you? I still have a tough time imagining this having enough demand to get added to Guava.

gissuebot commented 10 years ago

Original comment posted by letallecy on 2013-01-28 at 11:41 PM

Point taken. FYI, I use another workaround: when there is more than one value in a cell, I store a list in that cell instead. And when querying a particular column or row, I return a MultiMap, instead of a Map, which is created by iterating in the cells and checking which contains single data and which contains multiple data.

gissuebot commented 10 years ago

Original comment posted by gak@google.com on 2013-02-26 at 06:14 PM

I've mentioned it before, but I've always been highly skeptical of the argument that a Multitable does not have enough utility as it is exactly the model for one of Google's most popular storage abstractions. I'm pretty sure that Bigtable has proven its utility.

gissuebot commented 10 years ago

Original comment posted by kak@google.com on 2013-08-22 at 11:47 PM

Issue #1227 has been merged into this issue.

gissuebot commented 10 years ago

Original comment posted by kak@google.com on 2013-08-22 at 11:48 PM

(No comment entered for this change.)

Owner: gak@google.com

gissuebot commented 10 years ago

Original comment posted by roxton on 2013-09-05 at 09:11 PM

Use Case:

I have two parameterized fields, with relations. The first field is concrete, and the elements of the second field are being inferred based on valid relations.

I want a table: Multitable<sourceParameterIndex, targetParameterIndex, CandidateParameters> That way, based on the relation between each permutation of source and target parameter index, I can add candidate parameters, then take the intersection across sets for each source parameter, instantiate field elements for each permutation of filtered parameters, then filter those permutations based on constraints.

Right now, I've got some ugly code around: Table<sourceParameterIndex, targetParameterIndex, Set<CandidateParameters>>, but I'd love for Multitable to be part of Guava.

fgaule commented 9 years ago

+1 to Multitable

causis commented 9 years ago

We'd really like a multitable, it is outrageous that there isn't one already.

tterrag1098 commented 9 years ago

:+1:

cpovirk commented 9 years ago

I searched through Google's codebase for instances of Table<R, C, List> and similar.

'\b(Immutable)?Table<.*, .*, (List|Set|Collection|Iterable)<.*>>'

This gave 192 results. That's actually pretty surprisingly small for the Google codebase. But of course there are surely other users who reinvented this themselves with different combinations of collections. (And sometimes that's fine: Louis's suggestion of a Multimap with a composite key is often sufficient.)

Still, the complexity of this type would be large, as previously discussed. This led me to file #2170 for Tables.computeIfAbsent, which is basically the primitive that the JDK added to Map in lieu of adding a full Multimap and Multiset. It may be enough for many users here.

srstsavage commented 8 years ago

+1

Also: http://stackoverflow.com/questions/17057104/multimap-table-with-guava

gmjonker commented 8 years ago

+1

jfloff commented 7 years ago

+1

dhalleine commented 7 years ago

+1

genomescale commented 7 years ago

+1

dustin-johnson commented 7 years ago

+1

ghost commented 6 years ago

Hmm I'd like to make the attempt to implement one but before I even get to a pull request would you accept it? This issue seems a little dead it doesn't look like a resolution will be satisfactory rather leave it how it is.

ghost commented 6 years ago

+1

jbduncan commented 6 years ago

As described in https://github.com/google/guava/issues/2170#issuecomment-249962341, people seeking a Multitable class and currently using Table<K, K, Collection<V>> can potentially use ValueGraph<K, Collection<V>> instead (a similar but perhaps simpler data structure in some cases), if that would fit their use case better.

jrtom commented 6 years ago

common.graph.Network<K, V> might also be appropriate if your V values are unique and capable of acting as a key to their "endpoints" (aka row and column specifiers).