"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" -- That's essentially what i'm trying to get going. I just thought that I'd be able to map the property as read-only (not insert, not update), and always generated. -- However, I've not been able to get it to work.
RIA based on key associations. I know they can work together, and I understand I might need to do a little massaging pre & post database, but i still can't get the mappings to work correctly to load or save fully-solvent entities. I've read up on nhib cascade, but I don't know where I should be setting the cascade, and what affect that has on how i need to save the entities. I believe I should set it on my one-to-many mapping of Ticket.Notes, and set it to cascade all delete orphan, and this means that if i ever want to add a note to a new or existing ticket, I have to save the ticket to the nhib session, and NEVER the note(s). -- Is that correct? Secondly, I'm a little fuzzy on how to know if an entity is transient or persistent & whether it's in cache or not, and whether those 2 things are mutually exclusive. perhaps an example would help: - user loads up a grid of all tickets. (on the server: Session.Query<Ticket>()) - decides to edit one of them, double-clicks it. - because we want the user to work with fresh data (and set a lock if editing) we query the server again to get that specific ticket (Session.Load<Ticket>(ticketID) ) -- user adds a new Note to Ticket.Notes -- user saves now, after the user saves (and assuming no changes were made to the Ticket - adding a note to the Notes collection does not dirty the ticket - RIA thing), ONLY the new Note will come back to the server to be saved. However, the new note will have the TicketID FK set. (HINT: this is why the FK is so important...) At this point, I can assume the ticket has not been changed, so I load it from the database (preferably from the cache), but what you say about what's in the cache, what's the same instance, etc, worries me a bit. (I'm using the Normal cache setting, and my Session is persistent across service calls: singleton servicehelper instance) -- Is it correct to assume that for this scenario, I should always get the ticket instance, using newNote.TicketID, and then Session.Merge(loadedTicketWithNewNoteAdded)? ---- Should I use Get() or Load() for the ticket ?? ---- From what I understand, the only time Get will return null is if it doesn't exist in the database, and only time Load will throw an exception is for the same reason. How do I force NHib to force-load-from-db an item? (For instance, in the above scenario, does the second load of the ticket really load it from the database, or only from the cache?) ------ Joe Brockhaus [email protected] ------------ On Mon, Feb 7, 2011 at 4:59 PM, John Davidson <[email protected]> wrote: > 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. > -- 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.
