If you really want the FK as part of the object then just add it as it is as a simple property and then you become responsible for management of that property. NHibernate will not help you manage the values, nor will it stop you, but you must keep track of the relationships in your code yourself. Cascade does not play any part in this.
If you want cascade to function as designed then listen to the advice and build the object model with the collections correctly. You will find that the tables have the FK in them as you expect, if you also let NHibernate generate the ddl for your database. John Davidson On Mon, Feb 7, 2011 at 3:51 PM, Joe Brockhaus <[email protected]> wrote: > well, that still leaves me with 0 answers, and 2 concerns which really > shouldn't matter. > > DTOs: > -- RIA creates these for me, inherently, through generated code in the > client(Silverlight) project. > -- When RIA sends back my entities from the client, it translates them back > into my Ticket POCO. > -- I am using an MVVM approach. That has nothing to do with what i'm asking > about. (I'd explain more, but I've learned my lesson here: giving people > more information doesn't help find a solution) > > FKs in Domain: > -- OK, so NHib doesn't want them. So what? That should mean that to > NHibernate, there is no difference between my FK field and any other field. > -- I asked about mapping the FK as read-only, always-generated (to force > NHib to populate the value). > ---- Will that work? Why not? > > Regardless of what you think about my approach to the domain and needing > the FK in it, you're not telling me that NHibernate can't accomplish my > scenario: just that you don't want to help me figure out how, or that you > don't know how. The answer you and 'the other guys' are giving me is that > the ONLY way I can get the value of a FK into my domain, is as a field based > on the Note.Ticket object reference, and that the only way to map such an > object is to create yet another layer in my domain that takes the NHib proxy > and copies it to a new entity that has a property for that FK that the NHib > proxy object did not ... I find it hard to believe that's the ONLY > 'solution'. > If you can't (or don't want to) answer the question of 'how to solve this > whole problem', can you at least answer some of the questions which don't > require knowledge of the whole problem:??? > > QUESTION: > -- Does a one-to-many association necessarily mean that I should NEVER add > an object that is contained in the collection directly to the NHib session? > I thought this was a matter of how Cascade was set, but who knows ... > -- i.e - a new Note should be added to Ticket.Notes, and then Ticket > should be either saved or merged into the NHib session? > > If you read the other threads, then you know that I KNOW that NHibernate & > FNH can do what I'm wanting, as there is an example using FNH automapping. I > just can't make it work with manual mappings, and can't use automapping for > my application. > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" 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/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" 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/nhusers?hl=en.
