Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You <em>can</em> define <code>exampleMapping</code> is the second definition is in a separate file, and you use <code>&lt;import resource="..."/&gt;</code> to import one file into another, but it's a fragile approach, and easily broken.</p> <p>I suggest a more robust strategy. Replace the <code>exampleMapping</code> with a <code>Registry</code> class, which in turn contains and manages the mappings:</p> <pre><code>public MappingRegistry&lt;K,V&gt; { private final Map&lt;K,V&gt; mappings = new HashMap&lt;K,V&gt;(); public void addMapping(K key, V value) { mappings.put(key, value); } public Map&lt;K,V&gt; getMappings() { return Collections.unmodifiableMap(mappings); } } </code></pre> <p>Then, write a class which registers a mapping with the registry:</p> <pre><code>public class MappingRegistrar&lt;K,V&gt; { private final MappingRegistry&lt;K,V&gt; registry; private K key; private V value; @Autowired public MappingRegistrar(MappingRegistry&lt;K,V&gt; registry) { this.registry = registry; } public void setKey(K key) { this.key = key; } public void setValue(V value) { this.value = value; } @PostConstruct public void registerMapping() { registry.addMapping(key, value); } } </code></pre> <p>The your config becomes something like this:</p> <pre><code>&lt;bean id="mappingRegistry" class="com.xyz.MappingRegistry"/&gt; &lt;bean id="mappingA" class="com.xyz.MappingRegistrar" p:key="keyA" p:value="valueA"/&gt; &lt;bean id="mappingB" class="com.xyz.MappingRegistrar" p:key="keyB" p:value="valueB"/&gt; &lt;bean id="mappingC" class="com.xyz.MappingRegistrar" p:key="keyC" p:value="valueC"/&gt; </code></pre> <p>These mappings can now be scattered throughout your config in any way you see fit, and they will self-assemble. <code>ExampleServcie</code> is then injected with the <code>MappingRegistry</code> and extracts the mappings accordingly.</p> <p>It's a bit more work than what you already have, but it's a lot more flexible and less error prone. This is particularly valuable if you're trying to build an extensible framework of some kind; you want to put fewer constraints on how people use it.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to extend already defined lists and maps in Spring application context?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USskaffman
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow to extend already defined lists and maps in Spring application context?
      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. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI already used this mechanism to provide an extensible feature for special kind of filter/value-providers. Thought this would be to much overhead and there is an easier way to achieve this for lists/maps. Apparently not. I will implement it like you proposed. Maybe we will see such a spring-feature in future? Thank you!
      singulars
      1. PO
      1. UScodevour
    2. CO@codevour: I don't think this is overkill, I think this is good design. It's more robust, more explicit, and more readable than using a naked Map, in my opinion.
      singulars
      1. PO
      1. USskaffman
    3. COYou may be right, this could be a very generic way of doing this, the beans could also be anonymous. Thought a little about that, this fits well for my approach. Thank you again.
      singulars
      1. PO
      1. UScodevour
 

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