Is it possible to use Fluent NHibernate's PersistenceSpecification to test NHibernate mappings done via XML?
The PersistenceSpecification takes session as its only parameter, so I do not see reason why not.
Related
I have set NHibernate to not lazy load for my entities. But sometimes when I do queries I don't want all the children of the children to be loaded. The mapping is set up by Fluent NHibernate.
Is there any way when writing the sql for the query to specify which columns to lazy load?
I believe, you're using the wrong approach. Set all mappings to lazy load, and then in the queries eager load only what you really need. This way you won't kill the app.
You can override all the mappings defined in Fluent Mappings in conventions either in class mappings.
There also are different scenarios where NHibernate does the trick (for instance if you load / get one instance all the properties will be fetched as defined in mapping. If you get a list of items it will not happen unless you use Fetch method explicitly).
So could you provide some more details on your question to give an answer that is more precise?
In our project we use MVC3 with a domain model and NHibernate as DAL.
We configure NHibernate with fluent configuration using auto mapping.
At the moment we are trying to devise a validation strategy.
We need validations that go beyond data annotations.
One place where we are sure to catch all attempts to alter (and corrupt) the data would be the property setters. As some checks involve querying the database, we do not want to do that when NHibernate restored objects form the database.
So for this to be a viable solution: Can we instruct FluentNhibernate to satandard AutoMap to the backing fields of the properties.
Thanks.
You can explicitly tell FNH to use a backing field: unfortunately AutoMapping support looks unlikely out-of-the box as there doesn't seem to be anything applicable in the configuration options.
Using Fluent NHibernate, I have succeeded in setting up a global Filter on my NHibernate session, and using it in ClassMap classes. The Filter WHERE clause is appended to queries using that map automagically as it should - as described in other posts on this forum.
Fluent NHibernate does not implement ApplyFilter<> of SubclassMap, it is only implemented for ClassMap. It was easy to do a test by adding a filter through the back door, by passing a MappingProviderStore to the SubclassMap Constructor, and adding the filter to that. Inspecting the resulting classes in the debugger shows that everything is populated identically to a ClassMap. However, not surprisingly, this didn't work.
Can someone tell me if Filters SHOULD work with SubclassMap in NHibernate itself?
Is this therefore something that might eventually be supported (e.g. by implementing SubclassMap.ApplyFilter<>) in Fluent NHibernate?
Using Fluent NHibernate 2.1, with NHibernate 3.1
I'm supposing that fluent call apply filter the :
as per this Jira Entry, at Oct 2012 the function is not yet availavle in NH.
Is there any way to get references to the mapping objects that NHibernate creates from the XML files? How about the ClassMap objects that FluentNhibernate creates? I wanted to create some query generation functions (for row counts, etc.) using this information. Since I went through the trouble of mapping it, I ought to have access to it in code, right?
Actually, Fluent ClassMaps are translated to XML.
The ISessionFactory exposes a GetAllClassMetadata method that is probably what you need.
I have some entity types that I would like to lazy load. However, they have some internal (assembly) fields they expose, but are not used outside that class. These fields are compiler generated (F#) and I cannot change them. The an example exception is:
NHibernate.InvalidProxyTypeException:
The following types may not be used as
proxies: Mappings.MTest: field id#47
should not be public nor internal
I understand why NHibernate is doing this, and how having fields, if I accessed them, would mess up the lazy-loading properties of the proxies that are generated. However, since I know I won't be using the fields, can I override NHibernate somehow?
Is there any way I can say "ignore this field"? I'm using Fluent NHibernate, if that makes it easier.
Edit: I should also note, I'm using NHibernate 2.1.0 Alpha 2.
Edit2: The main gist here is that I want to keep LazyLoading enabled, which means I have to use the proxy generation. Disabling LazyLoading works (no proxies), but sorta defeats the purpose of a nice framework like NHibernate.
I reassembled NHibernate (easier than getting the source and rebuilding) and removed the code that errors on internal/public fields. LazyLoading appears to work just fine without that check. (Although, I'm new to NHibernate and so there are probably scenarios I don't know about.)
Edit:
Ah, there is a property, "use_proxy_validator" that will disable all validation checks. Good enough.
Fluently.Configure()
.ExposeConfiguration(fun cfg ->
cfg.Properties.Add("use_proxy_validator", "false"))...
Just set the lazy property to false,
<class name="OrderLine" table="OrderLine" lazy="false" >
you can read more in:
Must Everything Be Virtual With NHibernate? - http://davybrion.com/blog/2009/03/must-everything-be-virtual-with-nhibernate/
Ofir,
www.TikalK.com
You can use the
[XmlIgnore]
attribute to decorate the fields :)
Can you use an Interface to declare the fields "used" ?http://nhibernate.info/doc/nh/en/index.html#persistent-classes-poco-sealed
"Another possibility is for the class to implement an interface that declares all public members"
I don't know if NH use the same #transient annotation/attribute as the JAVA version to ignore a property in persistent operations.
You might want to take a look at this page which gives an overview of using F# with Fluent NHibernate.
Edit I just noticed your username. Am I correct in perhaps thinking that this is your blog? How foolish of me. It does seem to address your problem though, specifically "We start off by disabling LazyLoad because most of the properties are not virtual, and NHibernate will fail to validate the mapping. Instead, we explicitly LazyLoad things, like the Store reference."? Maybe I'm just misunderstanding the problem.