Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First : how does a HashMap work?</p> <p>Basically it has an array and when you put a key-value pair in the map, it is stored in one of the positions in the array. The position in the array is chosen based on the result of the key's <code>hashCode()</code> passed to a hashing method. Why is that? Well, if you request the value for a certain key, the index in the array to find the key and its associated value can simply be recalculated to find the index in the array again. (Some more logic is needed to deal with keys that map to the same index, but I'm just trying to get you to understand the basic mechanism) Then <code>equals()</code> is used to verify if the key at the calculated index is indeed the requested key.</p> <ol> <li><p>From this it should be a bit more clear why immutable keys are better than mutable keys. An immutable key will always keep the same <code>hashCode()</code> value, and the hashing function will find the correct bucket ( = index in the hashMap's array) again.</p> <p>That doesn't mean mutable keys cannot work. A mutable key will work if mutations on the key do not affect the hash code or if the keys are simply not mutated as long as the hashMap is used.</p></li> <li><p>How can an immutable key change? Well, the key itself may not be able to change, but the key-value mapping can change in business logic. If you create a map, using the address as a key, you rely on the fact that a store's address will not change. If a store's address changes, you'll not find it in the Map using its new address as a key. Your manager has a valid point.</p></li> <li><p>the speed of finding a key in a Map highly depends on the speed of calculating the hashCode. For a String this calculation loops over all the characters in the String. If you use long Strings as keys and have a lot of Map access this may lead to a performance bottle neck. Java's String implementation therefore caches the hash value, so it will be calculated only once. However you'll only avoid calculating the hash code if you use the same <code>String</code> instance again (new instances will not have the cached value). You may <code>intern()</code> the keys you use, but consider this only if it can be shown that there really is a performance bottle neck, as <code>String</code> interning does come with its own overhead.</p></li> <li><p>as explained in 1 : mutable keys can work if their hash code is not affected by mutations. e.g. using a Customer as key, where the <code>hashCode()</code> is based only on the customer's name, then a Customer implementation that only does not allow the name to change, yet allows other values to change, is a reliable key.</p></li> </ol>
    singulars
    1. This table or related slice is empty.
    1. POString as key in hashmap
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USbowmore
    1. USbowmore
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POString as key in hashmap
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COExcellent. Thanks bowmore.
      singulars
      1. PO
      1. USrickygrimes
    2. COString's hashcode is already cached...
      singulars
      1. PO
      1. USassylias
    3. CO@assylias edited my answer
      singulars
      1. PO
      1. USbowmore
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload