Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'm not entirely sure what you are trying to achieve. I don't think you can achieve exactly what you want without creating your own custom schema (which is non-trivial for nested structures), but the following example is probably pretty close without doing that.</p> <p>First, define an abstract bean to use as a template for your outer bean (my example uses a Car as the outer bean and an Engine as the inner bean), giving it default values that all other beans can inherit:</p> <pre><code>&lt;bean id="defaultCar" class="Car" abstract="true"&gt; &lt;property name="make" value="Honda"/&gt; &lt;property name="model" value="Civic"/&gt; &lt;property name="color" value="Green"/&gt; &lt;property name="numberOfWheels" value="4"/&gt; &lt;property name="engine" ref="defaultEngine"/&gt; &lt;/bean&gt; </code></pre> <p>Since all Honda Civics have the same engine (in my world, where I know nothing about cars), I give it a default nested engine bean. Unfortunately, a bean cannot reference an abstract bean, so the default engine cannot be abstract. I've defined a concrete bean for the engine, but mark it as <code>lazy-init</code> so it will not actually be instantiated unless another bean uses it:</p> <pre><code>&lt;bean id="defaultEngine" class="Engine" lazy-init="true"&gt; &lt;property name="numberOfCylinders" value="4"/&gt; &lt;property name="volume" value="400"/&gt; &lt;property name="weight" value="475"/&gt; &lt;/bean&gt; </code></pre> <p>Now I can define my specific car, taking all the default values by referencing the bean where they are defined via <code>parent</code>:</p> <pre><code>&lt;bean id="myCar" parent="defaultCar"/&gt; </code></pre> <p>My wife has a car just like mine, except its a different model (again, I know nothing about cars - let's assume the engines are the same even though in real life they probably are not). Instead of redefining a bunch of beans/properties, I just extend the default car definition again, but override one of its properties:</p> <pre><code>&lt;bean id="myWifesCar" parent="defaultCar"&gt; &lt;property name="model" value="Odyssey"/&gt; &lt;/bean&gt; </code></pre> <p>My sister has the same car as my wife (really), but it has a different color. I can extend a concrete bean and override one or more properties on it:</p> <pre><code>&lt;bean id="mySistersCar" parent="myWifesCar"&gt; &lt;property name="color" value="Silver"/&gt; &lt;/bean&gt; </code></pre> <p>If I liked racing minivans, I might consider getting one with a bigger engine. Here I extend a minivan bean, overriding its default engine with a new engine. This new engine extends the default engine, overriding a few properties:</p> <pre><code>&lt;bean id="supedUpMiniVan" parent="myWifesCar"&gt; &lt;property name="engine"&gt; &lt;bean parent="defaultEngine"&gt; &lt;property name="volume" value="600"/&gt; &lt;property name="weight" value="750"/&gt; &lt;/bean&gt; &lt;/property&gt; &lt;/bean&gt; </code></pre> <p>You can also do this more concisely by using <a href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/validation.html#beans-beans-conventions" rel="noreferrer">nested properties</a>:</p> <pre><code>&lt;bean id="supedUpMiniVan" parent="myWifesCar"&gt; &lt;property name="engine.volume" value="600"/&gt; &lt;property name="engine.weight" value="750"/&gt; &lt;/bean&gt; </code></pre> <p>This will use the "defaultEngine". However, if you were to create two cars this way, each with different property values, the behavior will not be correct. This is because the two cars would be sharing the same engine instance, with the second car overriding the property settings set on the first car. This can be remedied by marking the defaultEngine as a "prototype", which instantiates a new one each time it is referenced:</p> <pre><code>&lt;bean id="defaultEngine" class="Engine" scope="prototype"&gt; &lt;property name="numberOfCylinders" value="4"/&gt; &lt;property name="volume" value="400"/&gt; &lt;property name="weight" value="475"/&gt; &lt;/bean&gt; </code></pre> <p>I think this example gives the basic idea. If your data structure is complex, you might define multiple abstract beans, or create several different abstract hierarchies - especially if your bean hierarchy is deeper than two beans.</p> <p>Side note: my example uses properties, which I believe are much clearer to understand, both in Spring xml and in Java code. However, the exact same technique works for constructors, factory methods, etc.</p>
    singulars
    1. This table or related slice is empty.
    1. POspring - constructor injection and overriding parent definition of nested bean
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSingleShot
    1. USSingleShot
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POspring - constructor injection and overriding parent definition of nested bean
      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. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThis looks promising, although I will have to add properties to my beans - I'm presently using constructor injection. I read that spring supports nested properties syntax. Can a child bean definition override the parent using nested properties, e.g. <property name="engine.weight" value="800"/>. Then I don't need to know about what bean is already instantiated when I override.
      singulars
      1. PO
      1. USmdma
    2. COconstructor injection is pretty much the worst way to go with spring imho.
      singulars
      1. PO
      1. USJustin
    3. CO@Justin - couldn't agree more - using constructors places so many restrictions, it's hard to read and don't work on a friday. I'll be glad to change to property injection. The original code predates spring and spring was grafted into it. At the time spring was new and there was no clear advice which style of injection to choose, so we stuck with c'tor injection, but over time, advice sided more and more with properties injection.
      singulars
      1. PO
      1. USmdma
 

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