Can you reproduce the case where the default constructor overwrites the proxying? I've never seen it happen, and always share a constructor with NH until I find that I need to add parameters to it, in which case I split them off and leave the NH constructor empty.
Maybe this isn't best practice and I've just been lucky to avoid the scenarios where it can go wrong? On Wed, Oct 7, 2009 at 12:18 AM, Hudson Akridge <[email protected]>wrote: > Re: Property Accessor. I'm wrong :) Was thinking of a backing field for the > collection. Paul is correct, having it marked private shouldn't matter for > an automatic property. Sincere apologies for the confusion there. > > > On Tue, Oct 6, 2009 at 7:58 AM, Hudson Akridge > <[email protected]>wrote: > >> For reference: >> *public Role() >> {* >> * //Empty for NHibernate. Can even mark as protected/internal if >> wanted >> }* >> >> //Called by the model when building a new Role. This way the >> initialization logic required for an as of yet to be hydrated Role doesn't >> interfere with NHibernate calling the base constructor when a Role does get >> hydrated (and in my experience, overwriting the collection NHibernate >> retrieved with an empty one) >> *public Role(string name)* >> * { >> Privileges = new List<Privilege>();* >> * Name = name; >> }* >> >> Regarding the private setter, it's not a problem if the mapping specifies >> the proper accessor level of private, which I don't believe has been done, >> so that'll pose another problem when hydrating. You might want to either set >> it to protected/internal, or change the HasManyToMany PrivilegeMap to use >> a private accessor so you don't run into any issues during your next step, >> retrieval :) >> >> >> On Tue, Oct 6, 2009 at 7:39 AM, Hudson Akridge >> <[email protected]>wrote: >> >>> I apologize I didn't elaborate further ;) . I meant to move the >>> initializers to a non-default constructor. I've had horrible issues in the >>> past with initialization in the default constructor overwriting the proxying >>> that NHibernate does whenever it retrieves the class back from the database. >>> The issue wouldn't have cropped up until after Carmine had been able to >>> successfully save the object graph back though, which seems to have been the >>> problem in the first place. >>> Good catch on the save Paul, looks like that fixes the issue :) >>> >>> >>> On Tue, Oct 6, 2009 at 7:09 AM, CarmineM <[email protected]>wrote: >>> >>>> >>>> Hi Paul, >>>> >>>> Thank you so much for your effort and huge pointers. >>>> I'll give it a try as soon as I get home. >>>> >>>> I also have a doubt about the repository implementation. >>>> >>>> First off, I'll remove the confusion on the mappings. >>>> >>>> About the repository call to persist the objects, (as of now) it just >>>> calls the >>>> session's save method on the item passed. >>>> I don't use transactions, yet. >>>> >>>> Thanks again for your help. Will let you all know about the epilogue. >>>> >>>> >>>> >>> >>> >>> -- >>> - Hudson >>> http://www.bestguesstheory.com >>> http://twitter.com/HudsonAkridge >>> >> >> >> >> -- >> - Hudson >> http://www.bestguesstheory.com >> http://twitter.com/HudsonAkridge >> > > > > -- > - Hudson > http://www.bestguesstheory.com > http://twitter.com/HudsonAkridge > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
