I'm trying to make Fluent NHibernate's automapping ignore a Dictionary property on one of my classes, but Fluent is ignoring me instead. Ignoring other types of properties seems to work fine, but even after following the documentation and adding an override for the Dictionary, I still get the following exception when BuildSessionFactory is called:
The type or method has 2 generic parameter(s), but 1 generic argument(s) were provided. A generic argument must be provided for each generic parameter.
I've tried overriding by property name:
.Override<MyClass>(map => {
map.IgnoreProperty(x => x.MyDictionaryProperty);
})
and also tried implementing ignores using a custom attribute, both of which result in the same exception from BuildSessionFactory. The only thing so far that makes this exception go away is removing the Dictionary property entirely.
My question seems to be identical to this one which was never answered (though I'll expand the scope by stating it doesn't matter whether the dictionary is on an abstract base class; the problem always happens for me regardless of what class the property is on). Any takers this time around?
If you update to the latest version of Fluent NHibernate, IDictionarys are explicitly ignored automatically for this exact reason. This will remain the case until we can actually support them.
Related
I am generating a class in ByteBuddy.
As part of one method implementation, I would like to set a (let's just say) public instance field in another object to the return value of a MethodCall invocation. (Keeping the example public means that access checks etc. are irrelevant.)
I thought I could use MethodCall#setsField(FieldDescription) to do this.
But from my prior question related to this I learned that MethodCall#setsField(FieldDescription) is intended to work only on fields of the instrumented type, and, looking at it now, I'm not entirely sure why or how I thought it was ever going to work.
So: is there a way for a ByteBuddy-generated method implementation to set an instance field of another object to the return value of a method invocation?
If it matters, the "instrumented method" (in ByteBuddy's terminology) accepts the object whose field I want to set as an argument. Naïvely I'd expect to be able to do something like:
MethodCall.invoke(someMethod).setsField(somePublicField).onArgument(2);
There may be problems here that I am not seeing but I was slightly surprised not to see this DSL option. (It may not exist for perfectly good reasons; I just don't know what they would be.)
This is not possible as of Byte Buddy 1.10.18, the mechanism was originally created to support getters/setters when defining beans, for example. That said, it would not be difficult to add; I think it would even be easiest to allow any custom byte code to be dispatched as a consumer of the method call.
I will look into how this can be done, but as a new feature, this will take some time before I find the empty space to do so. The change is tracked on GitHub.
If you request an unbound object from NInject, then the default behaviour is (if a suitable constructor is available) appears to be to create an instance of the appropriate object.
I'd like to disable this behaviour (I had a difficult to debug issue because something was auto-bound instead of picking up my custom binding in a module). This question hints that it is possible, but I'm unable to find the answer from the NInject wiki.
Remove the SelfBindingResolver from the kernel components after creation:
kernel.Components.RemoveAll<IMissingBindingResolver>();
kernel.Components.Add<IMissingBindingResolver, DefaultValueBindingResolver>();
The following is a better, more direct way of removing the SelfBindingResolver, without assuming that the DefaultValueBindingResolver is the only other IMissingBindingResolver component:
kernel.Components.Remove<IMissingBindingResolver, SelfBindingResolver>();
It's possible the Remove<T, TImplementation>() method was only added in a recent version of Ninject, but this works for me using Ninject 3.2.2.0.
I used to do this (in setupContext in a subclass of SimpleModule):
DeserializationConfig dc = context.getDeserializationConfig();
dc.disable(Feature.CAN_OVERRIDE_ACCESS_MODIFIERS);
dc.disable(Feature.READ_ENUMS_USING_TO_STRING);
dc.disable(Feature.FAIL_ON_UNKNOWN_PROPERTIES);
But get deprecation warnings in 1.9, so I try :
DeserializationConfig dc = context.getDeserializationConfig();
dc.without(Feature.CAN_OVERRIDE_ACCESS_MODIFIERS)
.without(Feature.READ_ENUMS_USING_TO_STRING)
.without(Feature.FAIL_ON_UNKNOWN_PROPERTIES);
but this seems to have no effect, since after these calls
dc = context.getDeserializationConfig();
System.out.println(dc.isEnabled(Feature.CAN_OVERRIDE_ACCESS_MODIFIERS));
System.out.println(dc.isEnabled(Feature.READ_ENUMS_USING_TO_STRING));
System.out.println(dc.isEnabled(Feature.FAIL_ON_UNKNOWN_PROPERTIES));
prints
true
false
true
which seem to be the default values. What am I missing here ?
These methods create new instances, so you MUST assign them. They have been added to get to bit more functional style, trying to make most objects immutable, which in turn helps a lot with concurrency (basically can share instances without synhcronization).
Naming convention tries to make this clear: set - methods change state, withXxx() methods are "fluent factories".
That some frameworks use fluent methods purely for chaining, but in most cases these are for Builder objects (mutable), and then resulting immmutable objects have no methods for changing state; but there may be methods to create new Builders.
Jackson uses withXxx() methods in most cases, without builders (there are some cases where full builders are used, but these are minority).
As you correctly note, issue 686 is related to specific case of changing features via Module interface. This is an unfortunate side effect of other changes and needs to be addresses for the next release. But until you either need to change features directly via ObjectMapper (setDeserializationConfig(...), or configure(...), or use deprecated methods if you must use module interface.
We are in the progress of introducing PostSharp in one of our projects. It's been working great so far! There is one thing though that we haven't managed to solve: how to fire an advice conditionally.
Details:
- we have an attribute StopWatchAttribute which makes it possible to record the time needed to run methods
- this attribute accepts an enumeration "LoggingLevel" which is set in the config file with values like 0, 1, 2 etc
- this parameter is read in a base class called BaseService during runtime: new BaseService().CurrentLoggingSettings
- we tried to set up the attribute constructor like StopWatchAttribute(new BaseService().CurrentLoggingLevel) but we get a compile error: an attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type.
--> summary: we would like the advice to be called conditionally and the condition depends on the parameter in the constructor of the attribute.
Is this possible to do?
Thanks for your help,
Andras
You cannot give variables to attributes, PostSharp or not. Since you're already reading the values from the config, just set your aspect to do the same on the Initialize() method. Override it in the aspect class and then save the value to a local field. You can use that field throughout the aspect. This compiles the value into the aspect essentially hard coding it.
Or, you can pull the value from the config from your advice method (OnMethodStart, etc) so that you can change it in the config at runtime. This is a more 'flexible' way to do it as it doesn't hard code anything.
Remember, your variables are being set at Runtime. PostSharp is a post-compile framework which means it does it's work long before your variables are even known to JIT.
Is there an elegant/convinient way (without creating many "empty" classes or at least they should be not annoying) to have fluent interfcaes that maintain order on compilation level.
Fluent interfaces:
http://en.wikipedia.org/wiki/Fluent_interface
with an idea to permit this compilation
var fluentConfig = new ConfigurationFluent().SetColor("blue")
.SetHeight(1)
.SetLength(2)
.SetDepth(3);
and decline this
var fluentConfig = new ConfigurationFluent().SetLength(2)
.SetColor("blue")
.SetHeight(1)
.SetDepth(3);
Each step in the chain needs to return an interface or class that only includes the methods that are valid to use after the current step. In other words, if SetColor must come first, ConfigurationFluent should only have a SetColor method. SetColor would then return an object that only has a SetHeight method, and so forth.
In reality, the return values could all be the same instance of ConfigurationFluent but cast to different interfaces explicitly implemented by that class.
I've got a set of three ways of doing this in C++ using essentially a compile time FSM to validate the actions. You can find the code on github.
The short answer is no, there is no elegant or convenient way to enforce an order of constructing a class that properly impelemnts the "Fluent Interface" as you've linked.
The longer answer starts with playing devil's advocate. If I had dependent properties (i.e. properties that required other properties to be set first), then I could implement them something like this:
method SetLength(int millimeters)
if color is null throw new ValidationException
length = millimeters
return this
end
(NOTE: the above does not map to any real language, it is just psuedocode)
So now I have exceptions to worry about. If I don't obey the rules, the fluent object will throw an exception. Now let's say I have a declaration like yours:
var config = new Fluent().SetLength(2).SetHeight(1).SetDepth(3).SetColor("blue");
When I catch the ValidationException because length depends on the color being set first, how am I as the user supposed to know what the correct order is? Even if I had each SetX method on a different line, the stacktrace will just give me the line where the config variable was declared in most languages. Furthermore, how am I supposed to keep the rules of this object straight in my head compared to other objects? It is a cocophony of conflicting ideals.
Such precedence checks violate the spirit of the "Fluent Interface" approach. That approach was designed for conveniently configure complex objects. You take the convenience out when you attempt to enforce order.
To properly and elegantly implement the fluent interface there are a couple of guidelines that are best observed to make consumers of your class thank you:
Provide meaningful default values: minimizes need to change values, and minimizes chances of creating an invalid object.
Do not perform configuration validation until explicitly asked to do so. That event can be when we use the configuration to create a new fully configured object, or when the consumer explicitly calls a Validate() method.
In any exceptions thrown, make sure the error message is clear and points out any inconsistencies.
maybe the compiler could check that methods are called in the same order as they are defined.
this could be a new feature for compilers.
Or maybe by means of annotations, something like:
class ConfigurationFluent {
#Called-before SetHeight
SetColor(..) {}
#Called-After SetColor
SetHeight(..) {}
#Called-After SetHeight
SetLength(..){ }
#Called-After SetLength
SetDepth(..) {}
}
You can implement a state machine of valid sequence of operations and on each method call the state machine and verify if the sequence of operation is allowed or throw an exception if not.
I will not suggest this approach for Configurations though, it can get very messy and not readable