Databases
StackOverflow2013
Postsdbo
PONHibernate Futures returns Proxy sometimes, Entity others
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PONHibernate Futures returns Proxy sometimes, Entity others
    primarykey
    data
    text
    <p>I have a database fetch that handles a full object graph using multiple future queries. It looks something like this (class names have been changed to protect the innocent):</p> <pre><code>Foo foo; var fooFuture = Session.QueryOver&lt;Foo&gt;() .Where(f =&gt; f.Id == id) .Future(); // load up the Blah collection for the Foo Session.QueryOver&lt;Foo&gt;() .Fetch(f =&gt; f.Blahs).Eager .Where(f =&gt; f.Id == id) .Future(); // do a separate query for the BlahOptions -- this is needed // because if we did a Join and Join off of Foo, we'd get duplicate Blah // results and that's not good Session.QueryOver&lt;Blah&gt;() .Fetch(b =&gt; b.Options).Eager .Where(b =&gt; b.Foo.Id == id) .Future(); // load up the Attributes for the Foo Session.QueryOver&lt;Foo&gt;() .Fetch(f =&gt; f.Attributes).Eager .Where(f =&gt; f.Id == id) .Future(); foo = fooFuture.SingleOrDefault(); </code></pre> <p><em>NOTE: I can implement this in NHibernate LINQ, but the behavior remains the same.</em></p> <p><strong>The weirdness:</strong> <code>foo</code> will sometimes be of type <code>FooNamespace.Foo</code> (the correct, concrete type) and other times it will be <code>Castle.Proxies.FooProxy</code>.</p> <p>Whether I get the real type or a proxied type seems to depend on whether or not NHibernate has been used previously in the session. When this query occurs after other NHibernate queries, it returns a <code>FooProxy</code>. If it's the first use of the session, it returns a <code>Foo</code>.</p> <p><strong>Why does this happen? How can I prevent it from happening?</strong> I'm purposefully fetching the entire object graph of <code>Foo</code> to make sure there are no proxies. And graph itself doesn't contain any proxies, it's just the root <code>Foo</code> reference. The fact that the returned type depends on what NHibernate has done before seems to be the key (and really weird).</p> <p>A couple closing notes:</p> <ul> <li><code>NHibernateUtil.IsInitialized</code> returns true when fed a <code>FooProxy</code>, so I can't assure it's not a proxy that way</li> <li>I'm proxy-adverse because the graph will be serialized for caching purposes and deserialization croaks when working with <code>FooProxy</code></li> </ul> <p>Any insight is greatly appreciated!</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USkdawg
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. PONHibernate Futures returns Proxy sometimes, Entity others
      1. USUT-Fan-05
      1. VTFavorite
    2. VO
      singulars
      1. PONHibernate Futures returns Proxy sometimes, Entity others
      1. USOrigin
      1. VTFavorite
    1. COYou should use NH's caching capabilities, NOT serialize persistent entities.
      singulars
      1. PONHibernate Futures returns Proxy sometimes, Entity others
      1. USDiego Mijelshon
    2. COI'm doing this in addition to NH's caching capabilities. We want to store queries and full object graphs -- both of which would result in a 2nd level cache hit per entity using NH's default 2nd level behavior.
      singulars
      1. PONHibernate Futures returns Proxy sometimes, Entity others
      1. USkdawg
    3. COThe default behavior is not to cache anything. But both things can be cached easily.
      singulars
      1. PONHibernate Futures returns Proxy sometimes, Entity others
      1. USDiego Mijelshon
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload