Remove cyclic references from Automapper for Rest responses from EF - api

I have an m:n relationship between 2 entities:
Person (id, name, ...), PersonJob (personid, jobid), Job (id, jobname, ...)
I can easly read my data from EF, map it via Automapper and return it as a REST api result like this (Dto being my Data Transfer Obects for the api calls):
public class MappingProfile : Profile {
public MappingProfile() {
CreateMap<Person, PersonDto>();
CreateMap<PersonJob , PersonJobDto>();
CreateMap<Job, JobDto>();
...
public async Task<PersonDto?> GetPersonDetailsAsync(long id)
{
var person = await context.Persons
.Include(x => x.PersonJob ).ThenInclude(x => x.Job)
.SingleOrDefaultAsync(p => p.Id == id);
return person == null ? null : mapper.Map<Person, PersonDto>(person );
}
public async Task<JobDto?> GetJobDetailsAsync(long id)
{
var job = await context.Jobs
.Include(x => x.PersonJob ).ThenInclude(x => x.Person)
.SingleOrDefaultAsync(p => p.Id == id);
return job == null ? null : mapper.Map<Job, JobDto>(job);
}
The Mapper works pretty nice, handling the cyclic nature of the EF objects pretty well. A Person object contains multiple PersonJob objects. These have a reference back to the object and a reference to the Job, which itself has a reference back to the PersonJob object.
But when I pass this data back via the REST interface this all gets serialized in a HUGE json string. So the Person contains a PersonJob that contains the original Person that contains the same PersonJob, ...
I cannot add the fields as Ignore fields in the mapping as I need both "mapping directions" - coming from Person to Job and from Job to Person.
At the moment I am deleting the "back references" after the Mapping, but this is obviosly not a good solution and hard to maintain if the object structures are more complex.
Is there an elegant way?
regards,
Christoph

Related

EF Core include related ids but not related entities

Before I go creating my own SQL scripts by hand for this, I have a scenario where I want to get the ids of a foreign key, but not the entirety of the foreign entities, using EF Core.
Right now, I'm getting the ids manually by looping through the related entities and extracting the ids one at a time, like so:
List<int> ClientIds = new List<int>();
for (var i = 0; i < Clients.length; i++){
ClientIds.add(Clients.ElementAt(i).Id);
}
To my understanding, this will either cause data returns much larger than needed (my entity + every related entity) or a completely separate query to be run for each related entity I access, which obviously I don't want to do if I can avoid it.
Is there a straightforward way to accomplish this in EF Core, or do I need to head over the SQL side and handle it myself?
Model:
public class UserViewModel {
public UserViewModel(UserModel userModel){
ClientIds = new List<int>();
for (var i = 0; i < UserModel.Clients.length; i++){
ClientIds.add(Clients.ElementAt(i).Id);
}
//...all the other class asignments
}
public IEnumerable<int> ClientIds {get;set;}
//...all the other irrelevant properties
}
Basically, I need my front-end to know which Client to ask for later.
It looks like you are trying to query this from within the parent entity. I.e.
public class Parent
{
public virtual ICollection<Client> Clients { get; set; }
public void SomeMethod()
{
// ...
List<int> ClientIds = new List<int>();
for (var i = 0; i < Clients.length; i++)
{
ClientIds.add(Clients.ElementAt(i).Id);
}
// ...
}
}
This is not ideal because unless your Clients were eager loaded when the Parent was loaded, this would trigger a lazy load to load all of the Clients data when all you want is the IDs. Still, it's not terrible as it would only result in one DB call to load the clients.
If they are already loaded, there is a more succinct way to get the IDs:
List<int> ClientIds = Clients.Select(x => x.Id).ToList();
Otherwise, if you have business logic involving the Parent and Clients where-by you want to be more selective about when and how the data is loaded, it is better to leave the entity definition to just represent the data state and basic rules/logic about the data, and move selective business logic outside of the entity into a business logic container that scopes the DbContext and queries against the entities to fetch what it needs.
For instance, if the calling code went and did this:
var parent = _context.Parents.Single(x => x.ParentId == parentId);
parent.SomeMethod(); // which resulted in checking the Client IDs...
The simplest way to avoid the extra DB call is to ensure the related entities are eager loaded.
var parent = _context.Parents
.Include(x => x.Clients)
.Single(x => x.ParentId == parentId);
parent.SomeMethod(); // which resulted in checking the Client IDs...
The problem with this approach is that it will still load all details about all of the Clients, and you end up in a situation where you end up defaulting to eager loading everything all of the time because the code might call something like that SomeMethod() which expects to find related entity details. This is the use-case for leveraging lazy loading, but that does have the performance overheads of the ad-hoc DB hits and ensuring that the entity's DbContext is always available to perform the read if necessary.
Instead, if you move the logic out of the entity and into the caller or another container that can take the relevant details, so that this caller projects down the data it will need from the entities in an efficient query:
var parentDetails = _context.Parents
.Where(x => x.ParentId == parentId)
.Select(x => new
{
x.ParentId,
// other details from parent or related entities...
ClientIds = x.Clients.Select(c => c.Id).ToList()
}).Single();
// Do logic that SomeMethod() would have done here, or pass these
// loaded details to a method / service to do the work rather than
// embedding it in the Entity.
This doesn't load a Parent entity, but rather executes a query to load just the details about the parent and related entities that we need. In this example it is projected into an anonymous type to hold the information we can later consume, but if you are querying the data to send to a view then you can project it directly into a view model or DTO class to serialize and send.

Pulling a property up to the parent object level

Take the following NHibernate scenario:
I have two tables:
Header
HeaderID (int),
ForeignKey1 (int),
ForeignKey2 (int)
Child
ForeignKey1 (int),
ForeignKey2 (int)
Description (varchar)
...
Metric Shed Ton Of Other Columns That Im Not InterestedIn(various types)
I'm using Fluent NHibernate - I'd like to project the value of Description on the Child object into the parent (is that the correct terminology?!) - but obviously Child contains a lot of data in its columns - I don't want all that extra data, just the description...how do I get NH to produce the equivalent of the following query:
select
Header.*, Child.Description
from
Header
inner join
Child ON Header.ForeignKey1 = Child.ForeignKey1 AND Header.ForeignKey2 = Child.ForeignKey2
The only way I've got this working up to now is to use a Reference mapping to reference the child from the Header entity and then just created a non-mapped property on Header which pointed to Child.Description. Obviously this means that NH fetches the whole child object before it can query the value of Description
(I don't think the composite key is a problem here, the join seems to work fine - it's just how to get the data without getting all the non-interesting data)
At the moment my header entity looks like this:
public virtual int HeaderID { get; set; }
public virtual int KeyColumn1 { get; set; }
public virtual int KeyColumn2 { get; set; }
public virtual Child Child { get; set; }
public virtual string Description { get { return Child.Description; } }
The mappings for it:
Id(x => x.HeaderID);
Map(x => x.KeyColumn1);
Map(x => x.KeyColumn2);
References<Child>(x => x.Child).Fetch.Join().Columns("KeyColumn1", "KeyColumn2").ReadOnly();
Basically, I can't change the schema, I'm not interested in the rest of the data in the Child table, and I can't create views (can't change schema)
Anyone have any ideas if this is possible? I'm going to be querying a big list of Header objects, and I need that field from Child but I don't want the query to take forever!
Is this something I would have to do at the query level instead using hql or crit API?
Edit:
Trying to get this working using query API
Header.Session.QueryOver<Header>(() => parent)
.Where(h => h.HeaderID == 1)
.Inner.JoinQueryOver(x => x.Child, () => child)
.Select(x => x.HeaderID, x => x.ForeignKey1, x => x.ForeignKey2, x => child.Description);
Checking the SQL shows the query is exactly what I want - but I get an exception System.Object[] is not of type Header and cannot be used in this generic collection
I assume this is because what I'm getting is just an array of values from the Select() - any idea how I can transform this into a Header object?
Edit: I ended up with
Header.Session.QueryOver<Header>(() => parent)
.Where(h => h.HeaderID == 1)
.Inner.JoinQueryOver(x => x.Child, () => child)
.Select(x => x.HeaderID, x => x.ForeignKey1, x => x.ForeignKey2, x => child.Description)
.TransformUsing(new GenericResultTransformer(typeof(Header), "HeaderID", "ForeignKey1", "ForeignKey2", "Description"));
Which works just how I want it - if anyone has a better suggestion I'm open to it, but like I said, I can't touch the schema at all
There is the concept of lazy properties, but that is really for the opposite situation, i.e. there is a small number of properties that you want to exclude.
If this is for a presentation scenario, use can use any of NHibernate's query methods, to project just the columns you like - the query result need not be a complete entity. See for instance the select clause in HQL and LINQ, and the SetProjection() family in Criteria/QueryOver.

Insert new NHibernate entity and immediately assign to parent

I have parent and child objects BOOKLET and DEMOGRAPHICS_INFO in my Oracle database mapped as follows in my data layer:
public BookletMapping()
{
Table("BOOKLET");
Id(x => x.Id, m => m.Column("ID");
...
ManyToOne(x => x.DemographicsInfo, m => m.Column("DEMOGRAPHICS_INFO_ID"));
}
public DemographicsInfoMapping()
{
Table("DEMOGRAPHICS_INFO");
Id(x => x.Id, m => m.Column("ID");
...
}
I have intentionally left out the DemographicsInfo relationship to the Booklet because I don't need to traverse my entities that direction. The ManyToOne relationship will actually be a one-to-one.
I have written a test to ensure I can create a DemographicsInfo and immediately assign it to its parent Booklet, and that looks like this:
[Test]
public void ShouldSaveCorrectEntity()
{
var booklet = _unitOfWork.Get<Booklet>(4);
var demInfo = new DemographicsInfo();
_unitOfWork.Insert(demInfo);
booklet.DemographicsInfo = demInfo;
_unitOfWork.Save();
demInfo.Id.ShouldNotEqual(0);
}
When I call Save(), I get the following exception:
{"ORA-02291: integrity constraint (<schema>.BOOKLET_DEMOGRAPHICS_INFO_FK1) violated - parent key not found\n"}
This is because the demInfo object is not given an Id upon Insert(). My Insert implementation looks like this:
public void Insert<T>(T entity)
{
using (var transaction = _session.BeginTransaction())
{
_session.Save(objectToSave);
_session.Flush();
transaction.Commit();
}
}
Where _session is an NHibernate ISession. Because I have both Saved the new entity (it persists successfully) and Flushed my session, I would expect my demInfo variable to have an Id, but it remains 0, which is a foreign key violation when I try to save my parent object. Am I overlooking a step here? Should I rethink my pattern for adding a new child to an existing parent?
I have solved my issue. As it turns out, the Oracle convention of using Sequences for Id column values and populating them using Triggers on row insert disallows NHibernate from learning the Id upon persisting an entity. I added a Sequence Generator to my Id maps and Insert() now updates the Id on my transient entity upon save so I can assign the DemographicsInfo to my Booklet.DemographicsInfo.
Id(x => x.Id, m =>
{
m.Column("ID");
m.Generator(Generators.Sequence, a => a.Params(new { sequence = "SEQ_TABLE_ID" }));
});
Now my test passes with no exceptions.

NHibernate Search Index poco object throws TransientObjectException

When calling Index method on FullTextSession with plain poco object throws the error below, works fine with proxied object.
Stacktrace:
[TransientObjectException: the instance was not associated with this session]
NHibernate.Impl.SessionImpl.GetIdentifier(Object obj) +500
I'm trying to squeeze the performance out of the nhibernate select method I've got the following code:
public virtual IList<T> LoadSearch()
{
return Adapater.Session.QueryOver<T>()
.SelectList(e =>
{
e.Select(x => x.Id);
e.Select(x => x.Title);
e.Select(x => x.Description);
return e;
}).List<object[]>()
.Select(props => new T
{
Id = (Guid)props[0],
Title = (string)props[1],
Description = (string)props[2]
}).ToList();
}
Is there way to return a proxied result? or some how adapt the list to a proxied list?
I think you can only index objects that are associated with a session, i.e. proxied entities.
The plain POCOs you are returning didn't come from NH - so aren't associated with a NH session.
You could try using ISession.Lock(instance, NHibernate.LockMode.None); on each entity to associate it with the session, but I really don't know if that'd work.

Foreign key is null when NH save the childs collection

I try to map NHibernate to an existing database structure. Unfortunately I can not change the existing structure.
First I'll give some background and then explain the problem itself
Relational analysis is quite simple:
Log is the main Entity. he has one-to-one relationship with Form.
the foreign key is FormID.
Buyer & Seller are collection of the form entity.
The application should save the form entity together with the buyers and the sellers.
The problem is the primary key consisting of the Buyer & Seller entity.
The key composite from ForegineKey- FormID and an intenal ordering int number- tdNum
This is reflected in the following form FNH mapping
public class FormLogMap : ClassMap<FormLog>
{
public FormLogMap()
{
Table("BillOfSaleLog");
Id(x => x.FormId).Column("FormID").GeneratedBy.Native();
....
....
References<Form>(x => x.Form, "FormID").LazyLoad().ReadOnly();
}
}
public class FormMap : ClassMap<Form>
{
public FormMap()
{
Table("BillOfSaleForm");
Id(x => x.Id).Column("FormID").GeneratedBy.Foreign("Log");
...
...
HasOne<FormLog>(x => x.Log).Cascade.All();
HasMany(x => x.Buyers).KeyColumn("FormID").Inverse().Cascade.All();
HasMany(x => x.Sellers).KeyColumn("FormID").Inverse().Cascade.All();
}
}
public class BuyerMap : ClassMap<Buyer>
{
public BuyerMap()
{
Table("BillOfSaleBuyer");
CompositeId()
.KeyReference(x => x.Form, "FormID")
.KeyProperty(x => x.InnerOrderId, "tdNum1");
....
....
}
}
Seller is exectly the same
The problem occurs when I try to save the entity by the Edit Action
I'm using MVC to get the user data and make it an object.
The binding works fine and makes the object along with the collections.
But when I save an entity receive the following error:
I expect NHibernate be smart enough to set the Buyer & Seller foreign keys.
But in fact they remain without value.
The problem can be solved by setting foreign keys manually
as the following code:
//i have to set the form proerty in the childs
//without of the lines NH will try to save the childs it with FormID = null
foreach (var buyer in form.Buyers) { buyer.Form = form; }
foreach (var seller in form.Sellers) { seller.Form = form; }
But I'm looking for an elegant and correct solution
Thank you for reading
You don't show the code for adding a Buyer or Seller to a Form but it should look like this:
form.Buyers.Add(buyer);
buyer.Form = form;
Because Form is the inverse side of the relationships, you have to set the reference to Form on the many side. You should do this anyway so that the in-memory objects are correct. If the Buyer and Seller objects are already persistent in the same ISession than that should work.
According to this related question, HHibernate does not support cascade working with a composite key (as you have in BuyerMap). One of the answers does contain a hack to workaround this, but you will end up with a redundant column.