TableBuilder, similar to MultimapBuilder

[gissuebot]

Original issue created by joe.j.kearney on 2010-12-13 at 06:10 PM

---

RFE: a Table giving insertion ordering among elements. A first implementation, backed by LinkedHashMaps rather than their unordered cousins, would give cell iteration in cell insertion order within rows, in row creation order. A more sophisticated implementation would want to keep a linked list through the entries for genuine cell-entry-order.

The attached implementation of the first of these is more or less s/Hash/LinkedHash/g.

Are there plans for the usual suite of utilities to create your own tables in the spirit of Multimaps.new*Multimap(baseMap, supplier)? I haven't used these enough to have lots of use cases, but it's not difficult to think of some reasonable ones for at least insertion-ordered entries.

[gissuebot]

Original comment posted by kevinb@google.com on 2011-01-12 at 10:29 PM

---

(No comment entered for this change.)

---

Status: Accepted Labels: Type-Enhancement

[gissuebot]

Original comment posted by kevinb@google.com on 2011-07-13 at 06:18 PM

---

(No comment entered for this change.)

---

Status: Triaged

[gissuebot]

Original comment posted by fry@google.com on 2011-12-10 at 03:58 PM

---

(No comment entered for this change.)

---

Labels: Package-Collect

[gissuebot]

Original comment posted by fry@google.com on 2012-02-16 at 07:17 PM

---

(No comment entered for this change.)

---

Status: Acknowledged

[gissuebot]

Original comment posted by wasserman.louis on 2012-02-23 at 07:35 PM

---

Do we have a particular use case for this?

[gissuebot]

Original comment posted by wasserman.louis on 2012-04-05 at 04:07 PM

---

Is there anything about this that isn't satisfied by ImmutableTable, which preserves insertion order?

[gissuebot]

Original comment posted by joe.j.kearney on 2012-04-05 at 05:31 PM

---

You mean insertion order through the builder API?

Only the obvious, that you might want a mutable one which preserves order of mutations.

[gissuebot]

Original comment posted by wasserman.louis on 2012-04-05 at 05:38 PM

---

Rephrase: do we have any known real-world use cases that aren't answered by ImmutableTable.

[gissuebot]

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]

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

---

(No comment entered for this change.)

---

Status: Research

[gissuebot]

Original comment posted by robbin.alexander on 2013-08-28 at 09:51 AM

---

We have an ANTLR parser which inserts a new Row in every iteration. ImmutableMap doesn't fit here.

[gissuebot]

Original comment posted by m...@giltaji.com on 2013-10-14 at 11:11 PM

---

I have a real world example for this.

We have a POJO which executes a PreparedStatement, parses the ResultSet with a bit of business logic and stores it in a Table to pass back to the caller. The PreparedStatement includes an ORDER BY clause in the sql, but the Table's ordering tramples the sql ordering.

Since the ResultSet will vary based on the parameters passed to PreparedStatement (as well as the DB contents at runtime), ImmutableTable doesn't make sense.

The alternative would be to have the POJO pass the raw ResultSet back to the caller, but then we would need to do the parsing/business logic inside the caller instead of encapsulating it in the POJO.

Another alternative would be to construct a different row/column key that can be sorted in a TreeBasedTable (or even use indices of an ArrayBasedTable), but that seems a bit code-smelly as we would need to maintain the map of the sort-friendly keys/indices to the real keys. The caller would also need to know about the mapping of fake keys to real keys.

[kevinb9n]

Nowadays I think we can interpret this as a request for TableBuilder.