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.
And here goes yet another question on NHibernate.
This one most likely doesn't have a desired answer, but still - let's give it a try.
I'm currently putting all the efforts into mapping a domain model onto the database using NHibernate. This domain model comes from a framework which is heavily obfuscated. (Not that I have worked a lot with obfuscated code before, but this one in most of the places can be translated neither by Reflector, nor by Resharper.)
Everything went more or less fine until I faced an entity with a required many-to-one relationship represented by a property with no setter with obfuscated backed field.
Is it possible to reference this obfuscated field somehow? A very special IPropertyAccessor?
If not, how can I load a fully constructed entity? The only option to inject a related object is by using a constructor that accepts it. But at the time of instantiating of an entity being loaded, neither IInstantiator nor IInterceptor has any data of it apart from the key. Any other extension points that suit my need?
To allow NHibernate to access your field instead of property you can use this in your mappings:
access="field"
I'm trying to map a type where one of the properties is an XmlDocument but I get this error:
NHibernate.MappingException : An association from the table ChangeLog_TestAuditHistory refers to an unmapped class: System.Xml.XmlDocument
I am using Fluent NHibernate automappings. NHibernate version 3.0.0.4000 and Fluent NHibernate version 1.2.0.694. I know NHibernate is supposed to support xml columns, but I've never seen any examples using auto mappings.
That's probably a bug in Fluent, or a wrong convention... you probably need to tell it that XmlDocument is not an entity.
If you map it as a regular property, NH will use the correct mapping by default.
I want to (auto)map a base class and its derived class to two different tables, as described here by ayende (unioned subclasses).
however, according to fluent nHibernate's documentation, I don't see a way do do that.
the property in IAutoMappingOverride they refer to is "IsDiscriminated", but that only difrrentiates between table-per-heirarchy and table-per-subclass.
Is it possible that automapping doesn't support unioned subclasses? and if so- can anyone suggest a workaround?
thanks,
Jhonny
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.