Even without that much information, is it worth adding a new issue on JIRA for this?
On Wed, Nov 19, 2014 at 4:42 PM, Marcelo Zabani <[email protected]> wrote: > No problem, Ricardo. I want to help as much as possible :) > > I did what you asked, but *NullArgumentExceptions *were thrown all around > the place when using System.Linq's extension methods on the property. So I > tried to add *verificacoes = Enumerable.Empty<VerificacaoVersao>();* to > the constructor to avoid those, but both *Version 1 *and *Version 2* from > my last email fail my unit tests now. The value returned by the getter is > always an empty IEnumerable. > > On Wed, Nov 19, 2014 at 3:49 PM, Ricardo Peres <[email protected]> wrote: > >> Try using an auto-implemented property (change mapping accordingly): >> >> *public virtual IEnumerable<VerificacaoVersao> verificacoes { get; >> protected set; }* >> >> And let us know if it works. Yes, yes, I know, that's not what you >> have/want to have, but just for debugging. >> >> RP >> >> >> >> On Wednesday, November 19, 2014 4:32:21 PM UTC, Marcelo Zabani wrote: >> >>> We are using Fluent Nhibernate, and this is the relevant mapping >>> override section for our problem entity, *VersaoQuestao*: >>> >>> *mapping.HasMany(x => x.verificacoes)* >>> * .KeyColumn("versaoquestao_id")* >>> * >>> >>> .Access.ReadOnlyPropertyThroughLowerCaseField(FluentNHibernate.Mapping.Prefix.Underscore)* >>> * .Inverse()* >>> * .Cascade.All();* >>> >>> The code for the properties is as follows: >>> >>> *protected IList<VerificacaoVersao> _verificacoes;* >>> *public virtual IEnumerable<VerificacaoVersao> verificacoes* >>> *{* >>> * get* >>> * {* >>> * return _verificacoes ?? Enumerable.Empty<VerificacaoVersao>();* >>> * }* >>> *}* >>> >>> As you can see, "related_entities" is actually "verificacoes". The >>> strange thing is that this mapping has always worked. This is the first >>> time it fails us, and it seems to be when we a get a proxy of >>> *VersaoQuestao*. To further illustrate, using *Version 1* below >>> triggers the bug. *Version 2* works fine. >>> >>> *- Version 1 *(this one retrieves an instance of *VersaoQuestaoEntregue*, >>> associated many-to-one with a proxy of *VersaoQuestao*, which has the >>> property "verificacoes" with the nosetter one-to-many mapping): >>> >>> * VersaoQuestaoEntregue entrega = entregas.GetById(entregaId);* >>> >>> * // Do a bunch of work, add elements to "_verificacoes"* >>> >>> * // entrega.versao.verificacoes returns an empty IEnumerable, even >>> though "_verificacoes" has elements in it according to the debugger* >>> >>> *- Version 2* (this one eager fetches *VersaoQuestao* and works fine) >>> >>> * VersaoQuestaoEntregue entrega = >>> session.Query<VersaoQuestaoEntregue>()* >>> * >>> .Where(ent => ent.id <http://ent.id> == entregaId)* >>> * >>> .Fetch(ent => ent.versao)* >>> * >>> .FirstOrDefault();* >>> >>> * // Do a bunch of work, add elements to "_verificacoes"* >>> >>> * // entrega.versao.verificacoes returns an IEnumerable with all the >>> elements in "_verificacoes"! Things work fine.* >>> >>> >>> In fact, my Unit Test breaks/passes just by changing how we obtain the >>> instance of *VersaoQuestaoEntregue*. This led to me think that the >>> problem was with the proxy of *VersaoQuestao.* >>> >>> Any thoughts? >>> >>> On Wed, Nov 19, 2014 at 11:07 AM, Ricardo Peres <[email protected]> >>> wrote: >>> >>>> What is the exact call you are using to map the collection property? >>>> >>>> RP >>>> >>>> >>>> On Wednesday, November 19, 2014 1:05:57 PM UTC, Ricardo Peres wrote: >>>>> >>>>> There is a configuration setting to bypass the check. >>>>> >>>>> RP >>>>> >>>>> On Wednesday, November 19, 2014 12:15:22 PM UTC, Marcelo Zabani wrote: >>>>>> >>>>>> Oops, sorry for the typo, but it is actually a virtual property >>>>>> getter (I don't think the Session Factory would even be built if it >>>>>> weren't, right?). >>>>>> >>>>>> On Wed, Nov 19, 2014 at 7:17 AM, Ricardo Peres <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Have you tried setting related_entities property as virtual? >>>>>>> >>>>>>> RP >>>>>>> >>>>>>> >>>>>>> On Monday, November 17, 2014 7:40:48 PM UTC, Marcelo Zabani wrote: >>>>>>>> >>>>>>>> Hi everyone, before submitting this as a bug report, I want to make >>>>>>>> sure that I'm not seeing things, and want to know if there is any more >>>>>>>> information I can submit with the bug report to help. Here it goes: >>>>>>>> >>>>>>>> When an entity is lazy loaded, a One to Many collection mapped with >>>>>>>> the nosetter strategy is not respected, i.e. "Getting" the property >>>>>>>> does >>>>>>>> not execute the actual getter code. This does not happen with non >>>>>>>> proxied >>>>>>>> entities. >>>>>>>> >>>>>>>> In some more detail, I have a class named "ProblemEntity" with: >>>>>>>> >>>>>>>> *private IList<T> _related_entities = new List<T>();* >>>>>>>> *public IEnumerable<T> related_entities { get { return >>>>>>>> _related_entities; } }* >>>>>>>> >>>>>>>> Here "related_entities" is an inverse, one-to-many collection >>>>>>>> mapped with the nosetter access strategy, with a lowercase and >>>>>>>> underscored >>>>>>>> prefix backing field. Cascade is set to All. >>>>>>>> The problem arises when I have a proxy of "ProblemEntity": the >>>>>>>> public getter "related_entities" always returns an empty >>>>>>>> IEnumerable<T>, >>>>>>>> even when "_related_entities" contains something. Eager fetching >>>>>>>> "ProblemEntity" makes the problem go away. >>>>>>>> >>>>>>>> Sadly, I haven't been able to write a simple test case that elicits >>>>>>>> this behavior. I have written a Unit Test for my own application to >>>>>>>> catch >>>>>>>> this, and switching between the proxy and non-proxy versions does make >>>>>>>> the >>>>>>>> test fail/succeed. I encountered this with NHibernate 3.3.1 and tried >>>>>>>> to >>>>>>>> update to 4.0.2, but it is still happening. >>>>>>>> If there is any more information I can provide to make this useful, >>>>>>>> please tell me so. >>>>>>>> >>>>>>>> Thank you in advance, >>>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "nhusers" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> Visit this group at http://groups.google.com/group/nhusers. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "nhusers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/nhusers. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/nhusers. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
