Well, I agree that if I were starting out fresh, this wouldn't be the approach that I would take. However, I do have to play the ball where it lies, so to speak, and getting from Linq/SQL to NHibernate is a good first step.
I do have a bit of a concern about what I showed, regarding creating a placeholder instance for the associated entity, just so NH can update the rest of the fields. But all in all, it appears to work well for me, and allows me to map associations properly, and can I get all the HQL goodness I was after. So unless there's a specific hazard that you can see with that... On Sep 15, 4:16 pm, José F. Romaniello <[email protected]> wrote: > RSR you are using the wrong tool, and you are using the tool wrongly. > You are *trying* to do a lot of work that nhibernate is meant to do. > Please, be aware that it may take longer to re-write nhibernate in *your > *code, > than start using nhibernate properly. > > 2010/9/15 rsr <[email protected]> > > > actually, what I have found that I can do is like so > > > ApplicationDocument sourceDocument; // say this is an application > > level Document object that has values to be updated > > var dalDocument = > > sc.GetById<Document>(sourceDocument.DocumentID); // sc wraps my > > session and has some helper methods > > ... assign various fields from sourceDocument to dalDocument, > > > // for Folder, create just a skelatal reference to an NH Folder > > object just containing the ID > > // don't need to actually load the Folder. I'm not updating it > > dalDocument.Folder = new Folder { FolderID = > > sourceDocument.FolderID }; > > > sc.Save(dalDocument); // save and flush > > > That is, in the places where my NH entities want an associated object, > > I can create a dummy reference to one, with just the ID property > > populated. This seems to be good enough to get my update scenario to > > work. > > > I'm curious if this rings any alarms, or seems like a reasonable > > approach. > > > On Sep 15, 12:47 pm, Diego Mijelshon <[email protected]> wrote: > > > Use session.Load to get the references. > > > Otherwise, NH is hurting you here instead of helping. > > > > Diego > > > > On Wed, Sep 15, 2010 at 15:16, rsr <[email protected]> wrote: > > > > Well, since you asked, the reason I am avoiding traditional NH > > > > collection mapping is... > > > > > I am converting a moderate sized project from using Linq/SQL to NH. > > > > The project architecture has isolated all of the Linq/SQL at a > > > > particular layer from which it maps the DBML generated classes to some > > > > POCO classes that are what is used throughout the rest of the system. > > > > Including WCF messaging and caching, and these POCOs don't cache the > > > > entire graph, but rather an object with the ID of its associate (which > > > > lives in it's own cache collection). The problem with that comes when > > > > I need to re-hydrate the NH entity from a POCO, like in order to save > > > > it, and that POCO only has the ID of it's associate - not a POCO > > > > entity. > > > > > So, that's why I am doing, as you say, more of a DB model than a > > > > domain model at the NH layer. Over time, I may come back and convert > > > > these mappings to more standard NH associations, but for the initial > > > > migration, this is the approach I'm using. > > > > > And with this approach I am still able to use HQL to build the basic > > > > sorts of queries that are typically used in this application. That is, > > > > the inner join type that I mentioned initially. But, there are a > > > > couple of cases where left joins would be beneficial, and hence my > > > > initial question. > > > > > Which, once again, is whether there is some special HQL syntax that > > > > could be used to get outer join behavior without the associations. It > > > > appears that the answer is no, there isn't. > > > > > I haven't showed the mappings because, well, there isn't really much > > > > to show. But, fwiw here they are. I have omitted the properties that > > > > are not relevant to the association. > > > > > <class name="Folder" table="FileSvc.Folder" > > > > > <id name="FolderID" type="int" unsaved-value="0" > > > > > <generator class="native" /> > > > > </id> > > > > <property name="ParentFolderID" type="int" /> > > > > <property name="FolderName" type="string" length="255" not- > > > > null="true"/> > > > > </class> > > > > > <class name="Document" table="FileSvc.Document" > > > > > <id name="DocumentID" type="int" unsaved-value="0" > > > > > <generator class="native" /> > > > > </id> > > > > <property name="DocumentName" type="string" length="255" not- > > > > null="true"/> > > > > <property name="FolderID" type="int" not-null="true" /> > > > > </class> > > > > > On Sep 15, 5:27 am, Diego Mijelshon <[email protected]> wrote: > > > > > I'm interested in the reasons for NOT mapping your model. What you > > have > > > > now > > > > > is a DB model, not a domain model. > > > > > If you mapped your collection, it would be as easy as: > > > > > > select f, d > > > > > from Folder f > > > > > left join f.Documents d > > > > > > But you don't even need that. You can use "from Folder" and then just > > > > > navigate the Documents relationship as convenient. > > > > > If you set batch-size on the collection to a reasonable number, you > > avoid > > > > > the SELECT N+1 problem in one single step. > > > > > > Diego > > > > > > On Wed, Sep 15, 2010 at 00:22, rsr <[email protected]> wrote: > > > > > > > Each document has a FolderID column, which is a foreign key to its > > > > > > containing folder. > > > > > > > Normally, in NH, I you'd map this as a many-to-one on Document, > > > > > > pointing at Folder, and a collection of some sort on Folder, > > > > > > containing Documents. Right? But like I say, I'm not using any > > > > > > association mappings > > > > > > (i have my reasons, trust me). > > > > > > > Supposing my select was > > > > > > select f, d from .... > > > > > > > then ideally, I'd get back something like a list of tuples where > > the > > > > > > first item is the folder and the second is a document. Yes, I'd > > get > > > > > > a separate result for each document, with the same instance of the > > > > > > Folder as the other children of the same folder. I'd have to > > gather > > > > > > them up and build the collection by folder. No problem there. > > > > > > Empty folders would be represented by a tuple with folder and a > > null > > > > > > document. > > > > > > Or maybe every folder would have an entry with a folder and a null, > > > > > > whether it is empty or not. > > > > > > > Make sense? > > > > > > > On Sep 14, 7:05 pm, Diego Mijelshon <[email protected]> > > wrote: > > > > > > > If you have a FolderID in the Document, you are NOT mapping it as > > I > > > > would > > > > > > > imagine... > > > > > > > > Also, what are you trying to retrieve with your query? all > > folders > > > > with > > > > > > all > > > > > > > their documents? > > > > > > > > Diego > > > > > > > > On Tue, Sep 14, 2010 at 22:26, rsr <[email protected]> wrote: > > > > > > > > Say I've got two tables Folder and Document related as you can > > > > > > > > imagine, and mapped in NH using just a simple property FolderID > > on > > > > the > > > > > > > > Document entity. i.e. - no many-to-one mapping. > > > > > > > > > I can do an HQL inner join by using > > > > > > > > from Folder f, Document d where f.FolderID = d.FolderID > > > > > > > > and that's great. > > > > > > > > > My question is - how can I turn that into a left join, so that > > I > > > > can > > > > > > > > get folders that have no documents? > > > > > > > > > Thanks. > > > > > > > > > -- > > > > > > > > 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]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > <nhusers%[email protected]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[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]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[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]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[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]<nhusers%[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.
