Any Mapping using Fluent NHibernate - nhibernate

Nhibernate documentation specfies ReferenceAny() as a method to do the mapping inheritance trees.
Check doc here. However the code specifies the method as deprecated and will be removed in the next versions. Is there any other way to map this.

Only the ReferencesAny<TOther>(Member property) overload has been deprecated. ReferencesAny<TOther>(Expression<Func<T,TOther>> memberExpression) is still perfectly valid.
It's the same type of confusion as when people claim that Enum.ToString has been deprecated. The overloads that take an IFormatProvider have been deprecated, but the other ToString overloads are fine. The problem is that Intellisense shows the member stricken-out, even though only a subset of its overloads are actually obsolete.
For more information on using ReferencesAny in Fluent NHibernate, see my other answer: Mapping to multiple tables with Fluent nHibernate

Related

Nibernate / Fluent NHibernate : Using Filter with SubclassMap

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.

Fluent nHibernate, ToManyBase, Generic usage

I have discovered the method T Generic() in the abstract class ToManyBase<T, TChild, TRelationshipAttributes> but I cannot find any documentation or examples of how this is used, or what it does. Can anyone enlighten me a bit?
Nothing of significance.
It's the equivalent of the NHibernate generic= attribute, which is simply away of explicitly specifying that a collection is a generic one. A holdover from NHibernate's pre-generic days.

nhibernate automapping with union-subclass option

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

How to handle JPA annotations for a pointer to a generic interface

I have a generic class that is also a mapped super class that has a private field that holds a pointer to another object of the same type:
#MappedSuperclass
public abstract class MyClass<T extends MyIfc<T>>
implements MyIfc<T>
{
#OneToOne()
#JoinColumn(name = "previous", nullable = true)
private T previous;
...
}
My problem is that Eclipse is showing an error in the file at the OneToOne "Target Entity "T" for previous is not an Entity." All of the implementations of MyIfc are, in fact, Entities. I should also add that each concrete implementation that inherit from MyClass uses a different value for T (because T is itself) so I can't use the "targetEntity" attribute.
I guess if there is no answer then I'll have to move this JPA annotation to all the concrete subclasses of MyClass. It just seems like JPA/Hibernate should be smart enough to know it'll all work out at run-time. Makes me wonder if I should just ignore this error somehow.
My problem is that Eclipse is showing an error in the file at the OneToOne "Target Entity "T" for previous is not an Entity."
Yes, and even if T was extending an Entity, I am not aware of any JPA provider supporting this (that's just not part of the JPA spec anyway). For more feedback have a look at JPA Generic entities classes Mappedsuperclass are not possible! (very similar thread about EclipseLink):
No you will be unable to make the Entities generic. The provider will be unable to map the relationship to the specific type defined by the generic definition as this type is assigned when the Entity is created in code not where the Entity is defined. Remember when designating Generics the Collection (in this case) is limited only to those types. The Provider can not possibly be this restrictive on a per Entity instance basis. In some cases changing the type may result in entirely different tables being mapped for a single Entity instance and that is definitely not supported.
Since JDO supports persistence of interface fields (which is a similar concept to what you have here), and since DataNucleus JPA is built on top of the JDO capabilities, then it likely would allow you to persist such a field (I have an example using JDO that does something very similar, but without seeing the remains of your classes and persistence code its impossible to be definitive). Give it a try and see what happens.
Obviously that is beyond the JPA spec, hence if portability is a concern for you then have a think first
You can add a #OneToOne(targetEntity=SuperClassOfT.class) to your fields to make this work.
Check out How to implement polymorphic JPA entities with generic relations

Ignore public/internal fields for NHibernate proxy

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.