https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-80 mdsal <p>Presently, the only code generated by yangtools for objects is equals().</p> <p>This limits the possible scalable lookup methods for storing large number of objects to HashMap() and derivatives.</p> <p>There is a number of key areas where hashmap is known to be the wrong answer - v4 prefixes and routing tables, large numbers of tunnels, etc. These are better services by a variety of a Tree (f.e. B tree). </p> <p>Trees require a comparator which returns less, equal, more in order to be implemented. This is missing.</p> <p>Proposal:</p> <p>In addition to the current equals() to have a compare() method which by default returns the lexical compare of the string representation. </p> <p>If overrides and optimizations are implemented (f.e. for prefixes and ip addresses), more appropriate comparators can be implemented. Example - taking the prefix length into account when comparing prefixes so they can be arranged into a tree for a fast longest prefix match.</p> <p>Operating System: All<br/> Platform: All</p> MDSAL-80

Lack of default comparator

Improvement Resolved Won't Do Unassigned Anton Ivanov Tue, 21 Apr 2015 11:09:46 +0000 Fri, 9 Mar 2018 18:00:07 +0000 Thu, 27 Oct 2016 17:12:49 +0000 0 3 <p>Unless I am missing something, this can easily be addressed externally by supplying a specific Comparator for the collection in which the object is being stored.</p> <p>(In reply to Robert Varga from comment #1)<br/> &gt; Unless I am missing something, this can easily be addressed externally by<br/> &gt; supplying a specific Comparator for the collection in which the object is<br/> &gt; being stored. </p> <p>A Collection a B-tree does not make and all high performance algos for working with large routing tables, etc are tree/radix based. They are not based on sorted collection and only "intro level" ones are based on maps/hashmaps.</p> <p>If there is no comparator you cannot implement these in a standardized fashion so it can be reused, each implementation has to be bespoke.</p> <p>A.</p> <p>This is pretty much a question of how you integrate into a particular data structure. We simply cannot provide all of that integration unless there is a well-described common pattern and if a different structure, requiring different type of integration occurs, we will end up going back to basics.</p> <p>In your line of argumentation it is impossible to store objects which do not implement java.util.Comparable in a java.util.TreeMap.</p> <p>Except it is, as you can provide a java.util.Comparator at TreeMap instantiation time, which the implementation will consult to understand how the object being inserted/looked up compares to other objects.</p> <p>The same design pattern should be followed when integrating with external data structures.</p> Development External issue ID 3032 External issue URL Issue Type Rank 0|i02w6v: