-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 22 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: NHibernate query analyzer
PostPosted: Thu Dec 01, 2005 7:55 pm 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
Does anyone know how to get the NHibernate Query Analyzer to work? I've got an assembly which has mappings that use nullables and the query analyzer always chokes when I click build project.

Help?

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 01, 2005 8:06 pm 
Senior
Senior

Joined: Sat Sep 10, 2005 3:46 pm
Posts: 178
I've talked with the developer and for some reason he cant get it to work if you are using nullables. I dont think there has been an updated version for quite some time, so I am assumming that he hasnt been able to resolve the problem.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 02, 2005 3:53 pm 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
:cry:

Looks like a good tool, but without nullables I'm screwed!

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 02, 2005 4:16 pm 
Contributor
Contributor

Joined: Thu May 12, 2005 8:45 am
Posts: 226
The web page talks about why the author won't work with nullables. http://www.ayende.com/projects/nhibernate-query-analyzer/nullables.aspx


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 02, 2005 7:10 pm 
Expert
Expert

Joined: Fri Oct 28, 2005 5:38 pm
Posts: 390
Location: Cedarburg, WI
We've run into this problem in other scenarios, where Type.GetType() fails to find a type that's in a dynamically loaded assembly. We just wrote our own "type finder" that takes a fully qualified type name and searches either a specific list of assemblies passed, or all assemblies currently loaded in the AppDomain of the current thread.

I currently have the same problem now with NullableDateTimeType failing to be found by NHibernate. I've tried manually loading the assembly it's in and declaring a dummy variable with the type I want, just before NHibernate.Cfg.Configuration.AddXmlFile() is called, and NHibernate STILL can't find the type :(

PLEASE, this needs to be fixed ...


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 02, 2005 8:51 pm 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
Hmm. Sounds like a showstopper doesn't it?

The MSDN docs say that Type.GetType just won't work as expected for assemblies that aren't actually loaded from disk.

Quote:
GetType only works on assemblies loaded from disk. If you call GetType to look up a type defined in a dynamic assembly defined using the System.Reflection.Emit services, you might get inconsistent behavior. The behavior depends on whether the dynamic assembly is persistent, that is, created using the RunAndSave or Save access modes of the System.Reflection.Emit.AssemblyBuilderAccess enumeration. If the dynamic assembly is persistent and has been written to disk before GetType is called, the loader finds the saved assembly on disk, loads that assembly, and retrieves the type from that assembly. If the assembly has not been saved to disk when GetType is called, the method returns a null reference (Nothing in Visual Basic). GetType does not understand transient dynamic assemblies; therefore, calling GetType to retrieve a type in a transient dynamic assembly returns a null reference (Nothing).

To use GetType on a dynamic module, subscribe to the AppDomain.AssemblyResolve event and call GetType before saving. Otherwise, you will get two copies of the assembly in memory.




I wonder why NQA isn't loading the assemblies from disk...I'll have to take a look at the code and see if I can get my head around it. Maybe there's a kludge that will solve the problem...

Any pointers welcome Ayende!

Cheers,

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 04, 2005 6:42 am 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
Ok, after looking at this in a little more detail I concur that it's an issue that probably needs to be resolved in NHibernate itself.

Since the issue is that if NHibernate's Configuration.AddAssembly method is passed a dynamic assembly it's reflect helper can't find the types in that assembly then maybe a modification to the AddAssembly method to keep a table of the assemblies added and a modification to the ReflectHelper.GetClassForName to continue it's search if the standard Type.GetType call doesn't work; on failure of the Type.GetType method then the assembly could be located from the table of assemblies constructed during the AddAssembly method and then the Assembly.GetType could be used instead.

There might be a more efficient way to do this, but after a quick look through the code this was the first possiblity that occurred to me. Perhaps one of the developers might have some input on this?

Just a thought...it'd be nice if NHibernate would play nice with types loaded from dynamic assemblies.

Symon.

P.S. It's also possible that I'm completely off track here. If I am then just ignore this message!


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 05, 2005 11:10 am 
Contributor
Contributor

Joined: Wed May 11, 2005 4:59 pm
Posts: 1766
Location: Prague, Czech Republic
Yes, looks like we could use something more sophisticated than just Type.GetType... can somebody please create a JIRA issue? :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 05, 2005 1:14 pm 
Expert
Expert

Joined: Fri Oct 28, 2005 5:38 pm
Posts: 390
Location: Cedarburg, WI
I have the code to fix this, we've been using it in our own product for 2 years. I just need a little help getting started modifying Nhibernate. Could Sergey or someone else PM me on this?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 05, 2005 5:38 pm 
Expert
Expert

Joined: Fri Oct 28, 2005 5:38 pm
Posts: 390
Location: Cedarburg, WI
I was able to hack NHibernate by commenting out the AssemblyKeyFile attribute in AssemblyInfo.cs everywhere it was set to NHibernate.snk. I also had to rebuild everything referenced by NHibernate (NHibernateContrib, Nullables2, etc.) in order for those DLLs to accept NHibernate without a strong name. There has to be a better way ...

Anyway, here is the code to fix the problem. In Util\ReflectHelper.cs, make the following changes:

1. Add the following new method:
Code:
public static System.Type FindLoadedType(string assemblyQualifiedTypeName)
{
    System.Type foundType = System.Type.GetType(assemblyQualifiedTypeName, false);
    if (foundType != null)
    {
        return foundType;
    }

    //
    // If we get here, the type is probably in a dynamically loaded assembly.
    // For some reason, Type.GetType() can't find these.
    // Just look through the loaded assemblies to find it.
    //
    // If the type name is not assembly-qualified, then just search through
    // all loaded assemblies and return the first matching one found.
    //
    // TODO: Respect any assembly version number, culture or public key token
    // requested in the type name
    //

    int firstCommaPosition = assemblyQualifiedTypeName.IndexOf(",");
    bool usingAssemblyQualifiedName = (firstCommaPosition >= 0);

    string namespaceQualifiedTypeName = assemblyQualifiedTypeName;
    string searchAssemblyFullName = String.Empty;

    if (usingAssemblyQualifiedName)
    {
        namespaceQualifiedTypeName =
            assemblyQualifiedTypeName.Substring(0, firstCommaPosition);

        searchAssemblyFullName =
            assemblyQualifiedTypeName.Substring(firstCommaPosition + 1).Trim();
    }

    System.Reflection.AssemblyName loadedAssemblyName;
    string loadedAssemblyFullName;

    System.Reflection.Assembly[] loadedAssemblies =
        System.Threading.Thread.GetDomain().GetAssemblies();

    foreach (Assembly loadedAssembly in loadedAssemblies)
    {
        loadedAssemblyName     = loadedAssembly.GetName();
        loadedAssemblyFullName = loadedAssemblyName.FullName;

        if (!usingAssemblyQualifiedName ||
            loadedAssemblyFullName == searchAssemblyFullName)
        {
            foundType = loadedAssembly.GetType(namespaceQualifiedTypeName);
            if (usingAssemblyQualifiedName || foundType != null)
            {
                break;
            }
        }
    }

    return foundType;
}


2. Change ClassForName to
Code:
public static System.Type ClassForName(string name)
{
    System.Type foundType = FindLoadedType(name);

    if (foundType == null)
    {
        throw new TypeLoadException(String.Format("Type '{0}' is not loaded.", name));
    }

    return foundType;
}


3. In TypeFromAssembly and GetConstantValue, change Type.GetType to FindLoadedType.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 06, 2005 6:58 pm 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
JIRA issue created.

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 06, 2005 8:19 pm 
Contributor
Contributor

Joined: Wed May 11, 2005 4:59 pm
Posts: 1766
Location: Prague, Czech Republic
Thanks for creating the issue :) To Nels_P_Olsen, regarding the .snk issue, it might have helped you if you generated your own key and used it as a substitute, but you would have to rebuild libraries that depend on those signed by the original key of course.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 08, 2005 5:17 am 
Senior
Senior

Joined: Thu Aug 25, 2005 3:35 am
Posts: 160
That all being said, does that mean that nHibernate Query Analyzer would magically start working when build with a version of nHibernate that uses the proposed code?

Because I really miss having a way to see how nhibernate will form queries.
I have emailed the creator about the possibility of just replacing the 'nullables' types to their respective .net type. A very very dirty hack, which will certainly screw up the results, however, atleast most ppl would be able to work again.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 09, 2005 1:23 pm 
Expert
Expert

Joined: Fri Oct 28, 2005 5:38 pm
Posts: 390
Location: Cedarburg, WI
From what I understand, NQA won't pick up any hack you make to NHibernate unless you signed it with the official .snk file, since NQA doesn't make its source available. This appears to be a major problem for people testing out NHibernate mods -- apparently they can't test their changes with any software using NHibernate unless they can recompile that software to reference their non-signed (or differently signed) NHibernate hack ...

Let me know if I'm confused about this, but the current situation for wannabe NHibernate developers looks grim :(


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 09, 2005 2:22 pm 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
Actually, the source for NQA is available on Ayende's site. They have an Subversion repository you can download from (I've done it myself).

Symon


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.