Refactor sequential select

[maca88]

This PR moves the generated sequential statements form the root entity to its subclasses which then simplifies the ILoadable.Hydrate method as the root persister parameter is not needed anymore.

[hazzik]

This sequential select feature such a mess.....

[maca88]

This sequential select feature such a mess.....

And also a quite old one that hasn't changed since 2007 even in Hibernate.

I've restored the HasSequentialSelect behavior in order to avoid a breaking change and deprecate it in favor of GetSequentialSelect.

[fredericDelaporte]

This sequential select feature such a mess.....

What that feature is about? Eager fetch mode select on associations?

[hazzik]

What that feature is about?

It's about eager joins (<join fetch="select" ... >) inside of an entity. See here: https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate.Test/Join/JoinTest.cs#L47. It is a kind of an in-between of table-per-hierarchy and joined-subclass features.

About mapping like this:

nhibernate-core/src/NHibernate.Test/Join/Person.hbm.xml

Lines 7 to 72 in 1711b5c

	<class name="Person" table="person" lazy="true" discriminator-value="null">
	<id name="Id" column="person_id" unsaved-value="0">
	<generator class="native"/>
	</id>
	<!-- force is unnecessary, in case we had other unknown discriminator values -->
	<discriminator column="person_type" type="string" length="1" not-null="false" force="true"/>
	<property name="Name" not-null="true" length="80"/>
	<property name="Sex" not-null="true" update="false"/>
	<join table="address">
	<key column="address_id"/>
	<property name="Address"/>
	<property name="Zip"/>
	<property name="Country"/>
	</join>
	<join table="phone" optional="true">
	<key column="phone_id"/>
	<property name="HomePhone"/>
	<property name="BusinessPhone"/>
	<set name="OthersPhones" cascade="all" access="property">
	<key column="phone_id"/>
	<element column="phone" type="string" length="20"/>
	</set>
	</join>
	<join table="inversed_stuff" inverse="true">
	<key column="stuff_id"/>
	<property name="StuffName"/>
	</join>
	<subclass name="Employee" lazy="true" discriminator-value="E">
	<join table="employee" fetch="select">
	<key column="person_id"/>
	<property name="Title" not-null="true" length="20"/>
	<property name="Salary"/>
	<many-to-one name="Manager"/>
	<bag name="Meetings" cascade="all" inverse="true" access="property">
	<key column="person_id"/>
	<one-to-many class="Meeting"/>
	</bag>
	</join>
	</subclass>
	<subclass name="Customer" lazy="true" discriminator-value="C">
	<join table="customer" fetch="select">
	<key column="person_id"/>
	<property name="Comments"/>
	<many-to-one name="Salesperson"/>
	</join>
	</subclass>
	<subclass name="User" lazy="true" discriminator-value="U">
	<join table="t_user" fetch="select" optional="true">
	<key column="person_id"/>
	<property name="Login" column="u_login"/>
	</join>
	<join table="t_silly" fetch="select" optional="true">
	<key column="person_id"/>
	<property name="_Silly" column="`_Silly`" access="field"/>
	</join>
	</subclass>
	</class>

[fredericDelaporte]

There are some conflicts to resolve with #1922 merge into master. For AbstractEntityPersister, they do not look trivial.

[maca88]

Conflicts are resolved.

[bahusoid]

This logic is wrongly placed here. This calculation makes sense only for SingleTableEntityPersister. It's wrong for all others persisters (fills dictionary with 0 for all properties).

Ok. It makes sense for sequenitial select. But it contains info only about join elements inside subclasses and 0 for all other places. So GetSubclassPropertyTableNumber(string propertyName, string entityName) behaves quite differently to GetSubclassPropertyTableNumber(string propertyPath). Which is confusing.