Gazel provides a restricted usage for relations among persistent classes. In this document you can learn about the types of relations Gazel supports.
This relation is the most used type among all and the simplest one.
Above code is enough to set a many-to-one relation between
About One-to-Many Relations
Gazel does not configure NHibernate for one-to-many relations. So creating
List<T> properties on persistent classes will not cause a one-to-many relation.
This is because accessing a subset of child records is a more likely need than fetching all of them at once. If you want to fetch all of the child records, it is not too much of a burden anyway;
About One-to-One Relations
Gazel does support one-to-one relations through a convention. However, we don't see it practical enough and don't recommend it. Nevertheless, you can find an example of a one-to-one relation;
There are a few notes on this type of relation;
Accountclass does not have a query class. This means that you can access to
Accountrecords only through
Employeerecords. If you write a query class
Accounts : Query<Account>, one-to-one relation will not take place.
- Public methods of
Accountclass will not be business services. This means that you have to write public methods to
Employeeclass to expose business services of
- There is a special case for one-to-one relations.
context.Query<Employees>().SingleById(EmployeeId);statement will never cause N+1 select problem, that's why we put it in a property getter.
Accountclass will not have a corresponding column for
Employeeclass will have a column named
Eager-Fetching and Lazy-Loading
Gazel configures NHibernate to eager fetch persistent object with one level. This means that when you query a list of persistent objects, their parents will be fetched eagerly using an inner join. But their grandparents will be proxies to be loaded lazily.
When you query employees with something like
context.Query<Employees>().ByName("mike"), the resulting
Employee objects will have
Department objects eagerly fetched. However, when you try to access a property of their
Company object (other than Id property), a query will be executed using that
Company object's primary key.
Above code causes N+1 select problem, which can be a performance issue. If you encounter this problem, you need to consider selecting all grandparents (
Company) of the children (
Employee) with an additional query so that there will be only 2 queries in total.
This relation type enables you to map your properties to interfaces, which we refer to as Interface Mapping or Polymorphic Mapping.
For NHibernate to map this property to a table it needs two columns;
ParentId: The id value of related record, like in a Many-to-One relation,
ParentType: Type of related record.
NHibernate uses type column to know which table to select. This type information is retrieved from an enum that corresponds to
Conventions for one-to-any mapping are;
- For an interface named
- There should be an enum named
- Each enum member must be a persistent class and implement
I[Name]is mapped to a persistent class with a property named
ParentId) column stores the id value of the related record
ParentType) column store enum member values (
2), not member names (
In a query method, you can filter by object like this;
Or you can filter by type like this;
Unfortunately interface mappings cannot be fetched eagerly. So beware of N+1 select problems if you use this feature.