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]>
>
> > > > > > .
> > > > > > 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.
