table implementations with insertion ordering

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by joe.j.kearney on 13 Dec 2010 at 6:10

Attachments:

• LinkedHashBasedTable.java

[GoogleCodeExporter]

Original comment by kevinb@google.com on 12 Jan 2011 at 10:29

• Changed state: Accepted
• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by kevinb@google.com on 13 Jul 2011 at 6:18

• Changed state: Triaged

[GoogleCodeExporter]

Original comment by fry@google.com on 10 Dec 2011 at 3:58

• Added labels: Package-Collect

[GoogleCodeExporter]

Original comment by fry@google.com on 16 Feb 2012 at 7:17

• Changed state: Acknowledged

[GoogleCodeExporter]

Do we have a particular use case for this?

Original comment by wasserman.louis on 23 Feb 2012 at 7:35

[GoogleCodeExporter]

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

Original comment by wasserman.louis on 5 Apr 2012 at 4:07

[GoogleCodeExporter]

You mean insertion order through the builder API?

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

Original comment by joe.j.kearney on 5 Apr 2012 at 5:31

[GoogleCodeExporter]

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

Original comment by wasserman.louis on 5 Apr 2012 at 5:38

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 May 2012 at 7:43

• Added labels: Type-Addition
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by kevinb@google.com on 22 Jun 2012 at 6:16

• Changed state: Research

[GoogleCodeExporter]

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

Original comment by robbin.a...@gmail.com on 28 Aug 2013 at 9:51

[GoogleCodeExporter]

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.

Original comment by m...@giltaji.com on 14 Oct 2013 at 11:11

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:18

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit