NH-4079 - Component mapping without explicit column/table names causes column/table overlap

[nhibernate-bot]

Emanuel Wlaschitz created an issue — 19th September 2017, 19:16:14:

(follow-up to NH-3114)

When attempting to create an entity which has two components of the same type but no explicit mention of column names in the mapping, the result is an overlap of the two columns (being put on with the same name). The same happens for collections inside those components, except that they end up in the same table.

Initially discovered during the analysis for NH-3114, I attempted to (https://github.com/BhaaLseN/nhibernate-core/tree/NH-3114-implicit). But since this was more a coincidence rather than an actual use case (which also appears to not impact anyone out there so far by the lack of existing an issue report), I did not really invest too much time researching this further.

Relevant parts in all conciseness as follows:
{code:c#|title=Entities}public class Component
{
public string ComponentProperty { get; set; }
public ICollection ComponentCollection { get; set; } = new List();
}
public class Entity
{
public Guid Id { get; set; }
public Component FirstComponent { get; set; }
public Component SecondComponent { get; set; }
}

{code:c#|title=Mapping}var mapper = new ModelMapper();
mapper.Class<Entity>(rc =>
{
	rc.Id(i => i.Id, m => m.Generator(Generators.GuidComb));
	rc.Component(p => p.FirstComponent,
		m =>
		{
			m.Set(c => c.ComponentCollection,
				// table name omitted, expecting a reasonable default
				c => { },
				c => c.Element());
			// not specifying a column name here (and below) causes an insert failure during session.Flush
			m.Property(p => p.ComponentProperty);
		});
	rc.Component(p => p.SecondComponent,
		m =>
		{
			m.Set(c => c.ComponentCollection,
				// table name omitted, expecting a reasonable default
				c => { },
				c => c.Element());
			// not specifying a column name here (and above) causes an insert failure during session.Flush
			m.Property(p => p.ComponentProperty);
		});
});

Note that this is not specific to Mapping by-code, as the same mapping XML created here could've been written by hand and appears to be just as legal.

As a result, the following tables are created:

ComponentCollection (component_key, id)```
Both `Entity.FirstComponent.ComponentProperty` and `Entity.SecondComponent.ComponentProperty` are stored to/loaded from table `Entity`, column `ComponentProperty`.
Both `Entity.FirstComponent.ComponentCollection` and `Entity.SecondComponent.ComponentCollection` are stored to/loaded from table `ComponentCollection`.

It would be to be expected that at least one more (distinctly named) column is placed in the `Entity` table and yet another table would be created to hold the contents of the second component collection. Sane (or rather, predictable) names would probably prepend the component property name to make things a little more unique (similar to the fix added in NH-3114 which includes the parent path inside Mapping by-code to make sure mapping actions are applied to the correct target)