Support mixed formulas and columns

[fredericDelaporte]

Many mapping elements allow to define their columns or formulas by nested elements, but most of them do not support having both nested columns and formulas.

Follow-up to NH-2117, which has added this support to one-to-many.

Why not qualifying this as a bug by the way, since nothing tells anywhere columns and formulas are not to be mixed.
A workaround could be in some cases to use formulas for columns too, but that can cause troubles to the DDL generation, as it cannot detect columns needing to be created when they are mapped as formulas.

This issue was spotted while checking this example.

This PR is #1759 rebased and squashed without the mapping-by-code part, since this part has some debate on its method naming, causing it to be blocked.

Possible breaking change:

• Mappings mixing column elements and formula elements were taking into account only the formula elements. They will now take into account all elements.
• Mappings mixing column elements and/or formula elements with a column attribute or a formula attribute were silently ignoring the attribute. They will now throw.
• Mappings mixing a column attribute and a formula attribute were silently doing some best effort logic, either considering this as a two columns mapping, the second one being the formula (most cases), or only taking into account the formula (case of the <element> mapping). They will now throw.

[fredericDelaporte]

Wrong for column: that was the element which was taking precedence.
(NH-1007 is about adding the generator attribute as an alternate to specifying the element, when the user just needs to specify the generator name.)

[fredericDelaporte]

It was demonstrating nothing, since InvalidColumnName is a valid column name. And it was actually the name used in database.

[hazzik]

What's the precedence of elements and tags in other cases (eg. generators, etc.)?

[fredericDelaporte]

As implied by this comment, in the case of generator, the attribute takes precedence over the element. (It looks to me as if the implementor of NH-1007 was mistakenly believing this was the priority used for columns, although it seems column elements have always taken precedence over attributes.)

For subselect, which support has been added quite later (NH-2602), the attribute also takes precedence over the element.

As already written, for column (and for formula), the element takes precedence over the attribute, and this seems to be the case since the first versions of NHibernate.

[hazzik]

Ok, can we investigate Hibernate then?

[fredericDelaporte]

Hibernate does not support the generator attribute, it only supports the element.

For subselect, the attribute also takes precedence over the element.

For column and formula, that is even yet another rule: the formula attribute takes precedence over all, then column and formula elements are considered (so, these elements are taken into account if there is no formula attribute), and last the column attribute is used (so, it is used if there is neither a formula attribute nor column of formula elements).

But maybe there is some validity checks done before parsing that I have not spotted.

[hazzik]

There is some cleanup required regards using of interpolated strings ($)

[fredericDelaporte]

I have made the cleanup. Do you consider your first approval as still holding true?

[hazzik]

I’ll double check, but in principle - yes. I wanted to check something regarding the interfaces implemented (I think some of the classes are missing some interfaces, but I don’t remember the details)

[fredericDelaporte]

Maybe you are thinking about one case which allows a nested formula or column element, but which indeed does not allow multiple ones, reason why I have not changed it. (I do not remember which case it was either, I just remember having seen it when I have checked all possible cases requiring this change.)

[fredericDelaporte]

I have rechecked this, and spotted no forgotten case.

So,

As proposed on the development group, and since no continued grounded disagreement has been expressed there since one week after raised concerns being addressed, I intend to merge this PR next week (likely on Wednesday).

(I am issuing this notice on PR issued before starting to apply this handling of merges. I will not do it for new PR.)